Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Классы

Страницы: < 1 2 3 4 >
student_92 © (2011-01-12 11:31:00)
нужно ли в конструкторе вызывать inherited Create

type TMyClass = class(TObject) { ... } public { ... } constructor Create(const AItemName: string); { ... } end; constructor TMyClass.Create(const AItemName: string); begin inherited Create; // <- ? { ... } end;

oxffff (2011-01-14 21:32:00) [21]
N 3

TMytype=class
constructor create;virtual;abstract;
end;

TMytypeChild=class(TMytype)
protected
lList:TList;
public
constructor create;override;
destructor destroy;override;
function GetList:TList;
end;

constructor TMytypeChild.create;
begin
inherited;
if assigned(lList) then llist.Clear;
end;

destructor TMytypeChild.destroy;
begin
lList.free;
inherited;
end;

procedure TForm1.Button1Click(Sender: TObject);
var Mytype:TMytype;
begin
Mytype:=TMytypeChild.create;
Mytype.create;
Mytype.free;
end;

function TMytypeChild.GetList: TList;
begin
if not assigned(lList) then lList:=TList.create;
result:=lList;
end;

oxffff (2011-01-14 21:28:00) [22]

> KSergey © (14.01.11 20:08) [55]
> > 2. if assigned(List) then List.clear else List:=TList.
> Create;
>
> При каждом обращении тоже вставлять такую ахинею....

N 2

TMytype=class
constructor create;virtual;abstract;
end;

TMytypeChild=class(TMytype)
protected
List:TList;
constructor create;override;
destructor destroy;override;
end;

constructor TMytypeChild.create;
begin
inherited;
if assigned(List) then list.Clear else List:=TList.create;
end;

destructor TMytypeChild.destroy;
begin
List.free;
inherited;
end;

procedure TForm1.Button1Click(Sender: TObject);
var Mytype:TMytype;
begin
Mytype:=TMytypeChild.create;
Mytype.create;
Mytype.free;
end;

oxffff (2011-01-14 21:25:00) [23]

> KSergey © (14.01.11 20:08) [55]
> > 2. if assigned(List) then List.clear else List:=TList.
> Create;
>
> При каждом обращении тоже вставлять такую ахинею....
>
> Не, я бы понял, если бы все эти рассуждения были сказаны
> "для примера", "вот так вот еще можно сделать", дабы блеснуть
> (в хорошем смысле) глубиной и широтой познаний.
> Но настаивать на этом?!

Пример N 1:

TMytype=class
constructor create;virtual;abstract;
end;

TMytypeChild=class(TMytype)
protected
List:TList;
class function NewInstance: TObject;override;
constructor create;override;
destructor destroy;override;
end;

{ TMytypeChild }

constructor TMytypeChild.create;
begin
inherited;
List.Clear;
end;

destructor TMytypeChild.destroy;
begin
List.free;
inherited;
end;

class function TMytypeChild.NewInstance: TObject;
begin
result:=inherited NewInstance;
with TMytypeChild(result) do
begin
List:=TList.create;
end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var Mytype:TMytype;
begin
Mytype:=TMytypeChild.create;
Mytype.create;
Mytype.free;
end;

Ins (2011-01-14 20:49:00) [24]

> Leonid Troyanovsky © (12.01.11 22:13) [7]

В TObject, видимо, о потомках не подумали ))))

KSergey (2011-01-14 20:08:00) [25]
> 2. if assigned(List) then List.clear else List:=TList.Create;

При каждом обращении тоже вставлять такую ахинею....

Извините за переход на личности, но эти люди еще носят синие штаны...
Не, я бы понял, если бы все эти рассуждения были сказаны "для примера", "вот так вот еще можно сделать", дабы блеснуть (в хорошем смысле) глубиной и широтой познаний.
Но настаивать на этом?!

oxffff (2011-01-14 16:33:00) [26]

> Ega23 © (14.01.11 16:30) [53]
>
> > Наоборот чем сложнее и качественнее ты напишешь, тем больше
>
> > завязан на тебе шеф и работодатель. :)
>
> Ну тогда вызвать в деструкторе конструктор для реинициализации.
> :)

На воскрешение намекаешь. :)

Ega23 (2011-01-14 16:30:00) [27]

> Наоборот чем сложнее и качественнее ты напишешь, тем больше
> завязан на тебе шеф и работодатель. :)

Ну тогда вызвать в деструкторе конструктор для реинициализации. :)

oxffff (2011-01-14 16:28:00) [28]

> Ega23 © (14.01.11 16:14) [50]
>
> > oxffff © (14.01.11 16:07) [49]
>
>
> Серёж, академические рассуждения о сферических конях в вакууме
> - это прекрасно!
> Но ты же сам сказал, что не стал бы такое в коммерческом
> коде использовать.

Наоборот чем сложнее и качественнее ты напишешь, тем больше завязан на тебе шеф и работодатель. :)

oxffff (2011-01-14 16:24:00) [29]

> Ega23 © (14.01.11 16:14) [50]

Олег, я стараюсь рассмотреть вопрос не только с привычного угла.
А что если рассмотреть этот вопрос с другой стороны....

Подобравшись вплотную к первой версии YAR(в которой есть записи с instance и static методами, но нет ООП), начинаешь задуматься о решениях других людей в рамках ООП и причинах таких решений и их последствиях.

Ega23 (2011-01-14 16:14:00) [30]

> oxffff © (14.01.11 16:07) [49]

Серёж, академические рассуждения о сферических конях в вакууме - это прекрасно!
Но ты же сам сказал, что не стал бы такое в коммерческом коде использовать.
Собственно, на этом вопрос можно закрыть, либо в потрепаловку перенести, так сказать, "о высоких материях".

oxffff (2011-01-14 16:07:00) [31]

> KSergey © (14.01.11 15:27) [46]
> oxffff © (14.01.11 08:49) [43]
>
> list := TList.Create;

Существует по крайней мере еще 3 варианта решения этого вопроса.

1. Список создается по требованию.
2. if assigned(List) then List.clear else List:=TList.Create;
3. Проверка регистра dl.

Однако newinstance самый безболезненный.

oxffff (2011-01-14 15:59:00) [32]

> KSergey © (14.01.11 15:27) [46]
> oxffff © (14.01.11 08:49) [43]
> > Было бы убудительно привести конктретный пример, где это
>
> > конкретно может ударить по пальцам и что нельзя написать
>
> > по другому и писать нужно именно как
>
> Элементарно.
>
> Вот передо мной проект на дельфи. Сичтаим, что дельфи я
> знаю более-менее, и понимаю что и как пихать в конструкторы/деструкторы
> и как их вызывать по задумке создателя.
> При добавлении функциональности понадобился внутри объекта
> вложенный объект. Вещь вполне нормальная и естественная.
>
> Добавляю в конструктор объекта строчку, которая по определению
> только в конструкторе и должна жить:
>
> list := TList.Create;
>
> И вдруг выясняется, что дебил (хорошо, пусть будет умник)
> коллега/предшественник решил, что конструкторы можно вызывать
> где и когда угодно лишь потому, что они, видите ли, "семантически
> идентичны инициализации".
>
> Вы извините за эпитеты, но если вы не видите ничего страшного
> в применении такого подхода в коммерческом ПО....

Видимо знаете Delphi не настолько хорошо.
Читайте про NewInstance.

Ega23 (2011-01-14 15:40:00) [33]

> Давай посмотрим.

Объект с выделенным буфером внутри.
Clear перекидывает позицию "курсора" в ноль.
Destroy - вызывает FreeMem.
Выделение памяти - однократное, использование - многократное.

KSergey (2011-01-14 15:27:00) [34]
oxffff © (14.01.11 08:49) [43]
> Было бы убудительно привести конктретный пример, где это
> конкретно может ударить по пальцам и что нельзя написать
> по другому и писать нужно именно как

Элементарно.

Вот передо мной проект на дельфи. Сичтаим, что дельфи я знаю более-менее, и понимаю что и как пихать в конструкторы/деструкторы и как их вызывать по задумке создателя.
При добавлении функциональности понадобился внутри объекта вложенный объект. Вещь вполне нормальная и естественная.
Добавляю в конструктор объекта строчку, которая по определению только в конструкторе и должна жить:

list := TList.Create;

И вдруг выясняется, что дебил (хорошо, пусть будет умник) коллега/предшественник решил, что конструкторы можно вызывать где и когда угодно лишь потому, что они, видите ли, "семантически идентичны инициализации".

Вы извините за эпитеты, но если вы не видите ничего страшного в применении такого подхода в коммерческом ПО....

DiamondShark (2011-01-14 10:12:00) [35]

> oxffff © (14.01.11 08:49) [43]
> У меня единственный вопрос? :)Где можно ознакомиться с Вашими
> трудами в области конструкторов.

"Сперва добейся" детектед.
У меня единственный ответ: фсад.
Дискуссия закончена.

oxffff (2011-01-14 09:31:00) [36]

> DiamondShark © (13.01.11 18:59) [36]
>
> > oxffff © (13.01.11 17:20) [35]
> > У кого как.
>
> Наконец, вызывает большое сомнения сама необходимость реинициализации.
> Нет сценариев, в которых реинициализация дала бы преимущество
> перед повторной инстанциацией.

Если память выделяется в куче и освобождается из нее.
То завтраты на аллокацию нового и деаллокацию старого станут ощутимыми при большом количестве таких операций.

oxffff (2011-01-14 08:49:00) [37]

> DiamondShark © (13.01.11 18:59) [36]
>
> > oxffff © (13.01.11 17:20) [35]
> > У кого как.
>
> Ни у кого ни как.
> По-определению, конструктор переводит объект из состояния
> "Выделен" в состояние "Инициализирован", а метод реинициализации
> переводит объект из любого промежуточного состояния в состояние
> "Инициализирован".
> Иными словами, конструктор реализует одну единственную дугу
> графа состояний, а метод реинициализации должен реализовывать
> потенциально бесконечное множество дуг графа состояний.
> Даже в предельно примитивном случае, когда объект, кроме
> терминальных состояний, имеет только одно рабочее состояние,
> конструктор и реинициализатор реализуют разные дуги графа
> состояний. Даже если у тебя логика конструкции и реинициализации
> примитивны и вторая покравает первую, так, что тело конструктора
> сводится к единственному вызову реинициализатора, то это
> твой маленький секрет, деталь реализации, на которую клиент
> объекта ни в коем случае не имеет права полагаться.
>
> Возможность вызова конструктора как метода -- это именно
> багофича конкретной реализации языка, появившаяся ради неусложнения
> компилятора. Никогда конструктор не задумывался как реинициализатор.
> Никакие объекты стандартной библиотеки не проектировались
> с возможностью использования конструктора как реинициализатора,
> никогда такой сценарий не документировался. Никогда такой
> сценарий не должен использоваться в новом дизайне, потому
> что нарушает привычные паттерны сложившейся практики, требует
> особого документирования, и, кроме вырожденных случаев,
> не даёт никакой экономии.
>
> Наконец, вызывает большое сомнения сама необходимость реинициализации.
> Нет сценариев, в которых реинициализация дала бы преимущество
> перед повторной инстанциацией.

У меня единственный вопрос? :)
Где можно ознакомиться с Вашими трудами в области конструкторов.
В других языках аллокатор указывается явно как new

Например help говорит, что обычно вызывается, но не говорит, что вызывать вне конструктора плохо.

When a constructor is called using an object reference (rather than a class reference), it does not create an object. Instead, the constructor operates on the specified object, executing only the statements in the constructor's implementation, and then returns a reference to the object. A constructor is typically invokedon an object reference in conjunction with the reserved word inherited to execute an inherited constructor

Теперь по дугам графа

Было бы убудительно привести конктретный пример, где это конкретно может ударить по пальцам и что нельзя написать по другому и писать нужно именно как только две отдельные реализации при условии что и конструктор и реинициализатор переводят объект в идентичное состояние. Пусть даже пример этот будет надуман.

Leonid Troyanovsky (2011-01-13 22:33:00) [38]

> KSergey © (13.01.11 09:27) [12]

> Потомки конкретного класса не будут конструироваться через
> фабрику. Никогда.

Ну, и хрен с ней, с фабрикой.

--
Regards, LVT.

Leonid Troyanovsky (2011-01-13 22:31:00) [39]

> Ega23 © (13.01.11 00:14) [8]

> Во всех остальных случаях точно также статичный метод через
> inherited можно вызвать.

Можно вызвать.
А зачем, если конструктор виртуальный.

> Тебя ведь не удивляет вызов

Меня уже давно никакой вызов не удивляет ;)

--
Regards, LVT.

DiamondShark (2011-01-13 20:51:00) [40]

> Ega23 © (13.01.11 20:43) [39]
> Полно.

Три примера найдёшь?

> Сам недавно такую схему реализовывал.

Давай посмотрим.

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »