ООП - помогите разобраться.

← →
parovoZZ © (2006-06-30 03:11) [0]

Здарова

Вот никак не могу разобраться в этом лесу.
В исходниках вижу

MyClass.Ceate;
и
MyClass := TMyClass.Create;

В чём разница?

← →
Джо © (2006-06-30 03:21) [1]

> В исходниках вижу
>
> MyClass.Ceate;

Показывай.

← →
Германн © (2006-06-30 03:25) [2]

> MyClass.Ceate;
и
MyClass := TMyClass.Create;

Во втором случае создаётся новый экземпляр(объект) класса TMyClass и выполняется его метод Create.
В первом выполняется метод Create уже созданного ранее объекта TMyClass .

← →
Джо © (2006-06-30 03:30) [3]

> В первом выполняется метод Create уже созданного ранее объекта
> TMyClass .

Не мне говорить, но Create-таки это конструктор, а не обычный метод, даже, я бы сказал, отчасти class function. Вот и хотелось бы взглянуть на сей дивный исходник — какая такая нужда заставила его вызывать у экз. класса. :)
Если, конечно, он и на самом деле не называется (как в оригинале) Ceate :)

← →
Германн © (2006-06-30 03:49) [4]

> Не мне говорить, но Create-таки это конструктор, а не обычный
> метод, даже, я бы сказал, отчасти class function. Вот и
> хотелось бы взглянуть на сей дивный исходник — какая такая
> нужда заставила его вызывать у экз. класса. :)Если, конечно,
> он и на самом деле не называется (как в оригинале) Ceate
> :)

Лично мне глядеть уже ни на что не хочется! И время не подходящее и обстоятельства. Но метод Create, как конструктор, имеет исторически две функции - 1. создать и 2. инициализировать. Как метод класса он выполняет и то и другое. Как метод объекта(экземпляра класса) он выполняет только второе.

А вопрос то "В чём разница?". А не в конкретном коде!

← →
parovoZZ © (2006-07-08 21:49) [5]

А чем отличается destroy от free? В справке написано, что при уничтожении объекта следует вызывать Free, а не destroy.

← →
Virgo_Style © (2006-07-08 21:55) [6]

parovoZZ © (08.07.06 21:49) [5]
там же написано, что Free automatically calls the destructor if the object reference is not nil.

← →
PSPF2003 © (2006-07-08 22:02) [7]

> А чем отличается destroy от free? В справке написано, что
> при уничтожении объекта следует вызывать Free, а не destroy.
>

Читал видно через строчку:)

← →
Шпиён (2006-07-08 22:24) [8]

> Джо © (30.06.06 03:21) [1]
> > В исходниках вижу
> >
> > MyClass.Ceate;
>
> Показывай.

А то не видел никогда -)
with TResourceStream.Create(HInst, ResName, RT_RCDATA) do try Instance := ReadComponent(Instance); finally Free; end;
(c) classes.pas

← →
Шпиён (2006-07-08 22:44) [9]

Упс...sorry. Был не внимателен. Не заметил, что MyClass.Create, а не TMyClass.Create

← →
tesseract © (2006-07-09 12:08) [10]

Creatе - функция создаёт экземпляр класса и возвращает его ссылку.
Если ты не укажешь переменную, то класс "повиснет" в памяти - его нельзя будет использовать или освободить "вручную".

with TResourceStream.Create(HInst, ResName, RT_RCDATA) do

В данном случае создаётся "невидимая" переменная и с ней выполняются действия через with, в конечном счёте класс освободиться в finally.

Free от destroy отличается тем, что Free сначала проверяет, существует ли класс.

я предпочитаю FreeAndNil.

← →
Пусик © (2006-07-09 18:22) [11]

> tesseract © (09.07.06 12:08) [10]
>Если ты не укажешь переменную, то класс "повиснет"
> в памяти - его нельзя будет использовать или освободить
> "вручную".

Необязательно. Вот пара примеров:

type TThr=class(TThread) procedure Execute; override; end; procedure TThr.Execute; begin FreeOnTerminate := True; end;

Вызываем - TThr.Create;

Второй пример:

type

TMyObj=class; TMyLabel=class(TLabel) private FObj: TObject; public constructor CreateLabel(aOwner: TComponent; aParent: TWinControl;aObj: TMyObj); destructor Destroy; override; end; TMyObj=class public constructor Create(aOwner: TComponent; aParent: TWinControl); destructor Destroy; override; end; { TMyObj } constructor TMyObj.Create(aOwner: TComponent; aParent: TWinControl); begin if aOwner=nil then raise Exception.Create("Set Owner component"); TMyLabel.CreateLabel(aOwner,aParent,Self); end; destructor TMyObj.Destroy; begin MessageBox(Application.Handle,"Однако, меня кто-то уничтожил!","Хм...!",MB_OK); inherited; end; { TMyLabel } constructor TMyLabel.CreateLabel(aOwner: TComponent; aParent: TWinControl;aObj: TMyObj); begin inherited Create(aOwner); FObj := aObj; Top := 100; Left := 100; Height := 200; Caption := "test label"; Width := 100; Parent := aParent; end; destructor TMyLabel.Destroy; begin FObj.Free; inherited; end;

Вызываем -

procedure TForm1.Button2Click(Sender: TObject); begin TMyObj.Create(Form1,Form1); end;

← →
Leonid Troyanovsky © (2006-07-09 18:51) [12]

> Пусик © (09.07.06 18:22) [11]

> Второй пример:

Мутный какой-то пример.
Вот, если б, было что-то вроде TWinControl.Parent,
тогда б, было значительно ясней.

Ну, или, на худой конец, Notification.

--
Regards, LVT.

← →
tesseract © (2006-07-09 19:01) [13]

> [11] Пусик © (09.07.06 18:22)
>
> > tesseract © (09.07.06 12:08) [10]
> >Если ты не укажешь переменную, то класс "повиснет"
> > в памяти - его нельзя будет использовать или освободить
>
> > "вручную".
>
>
> Необязательно. Вот пара примеров:
>
> type
> TThr=class(TThread)
> procedure Execute; override;
> end;
>
> procedure TThr.Execute;
> begin
> FreeOnTerminate := True;
> end;
>
>
> Вызываем - TThr.Create;
>
> Второй пример:
>
> type
>
> TMyObj=class;
>
> TMyLabel=class(TLabel)
> private
> FObj: TObject;
> public
> constructor CreateLabel(aOwner: TComponent; aParent:
> TWinControl;aObj: TMyObj);
> destructor Destroy; override;
> end;
>
> TMyObj=class
> public
> constructor Create(aOwner: TComponent; aParent: TWinControl)
> ;
> destructor Destroy; override;
> end;
>
> { TMyObj }
>
> constructor TMyObj.Create(aOwner: TComponent; aParent: TWinControl)
> ;
> begin
> if aOwner=nil then raise Exception.Create("Set Owner component")
> ;
> TMyLabel.CreateLabel(aOwner,aParent,Self);
> end;
>
> destructor TMyObj.Destroy;
> begin
> MessageBox(Application.Handle,"Однако, меня кто-то уничтожил!
> ","Хм...!",MB_OK);
> inherited;
> end;
>
> { TMyLabel }
>
> constructor TMyLabel.CreateLabel(aOwner: TComponent; aParent:
> TWinControl;aObj: TMyObj);
> begin
> inherited Create(aOwner);
> FObj := aObj;
> Top := 100;
> Left := 100;
> Height := 200;
> Caption := "test label";
> Width := 100;
> Parent := aParent;
> end;
>
> destructor TMyLabel.Destroy;
> begin
> FObj.Free;
> inherited;
> end;
>
> Вызываем -
>
> procedure TForm1.Button2Click(Sender: TObject);
> begin
> TMyObj.Create(Form1,Form1);
> end;

Пусик про owner/parent мне прекрасно известно. Только слабо так-же, но не для компонента? А для объекта?

ЗЫ: не парьте человеку мозги.

← →
Пусик © (2006-07-09 19:25) [14]

> Только слабо так-же, но не для компонента? А для объекта?

А чем они отличаются?

> ЗЫ: не парьте человеку мозги.

Не надо выдавать знания порциями. Не твои это функции.

← →
tesseract © (2006-07-09 21:26) [15]

> А чем они отличаются?

Наверно тем что объект ссылки на подчинённые не хранит,
именно это ты и делаешь - записываешь ссылку на компонет. Который освободиться при уничтожении объека родителя.
Вопрос был про ООП, а не VCL.

← →
Пусик © (2006-07-09 21:31) [16]

> Наверно тем что объект ссылки на подчинённые не хранит,

Разве кто-то запрещает в полях объекта хранить любую информацию?

← →
tesseract © (2006-07-09 21:33) [17]

> Разве кто-то запрещает в полях объекта хранить любую информацию?

Храни, что хочешь, но к вопросу это не относиться.

← →
Пусик © (2006-07-09 21:43) [18]

> tesseract © (09.07.06 21:33) [17]
> > Разве кто-то запрещает в полях объекта хранить любую информацию?
> Храни, что хочешь, но к вопросу это не относиться.

Это почему это не относится?
--------------------

Хочу также заметить, что вот это

> tesseract © (09.07.06 21:26) [15]
> > А чем они отличаются?Наверно тем что объект ссылки на
> подчинённые не хранит,

имеет явный запах сказки.

Вот на это

> tesseract © (09.07.06 12:08) [10]
> Creatе - функция создаёт экземпляр класса и возвращает его
> ссылку. Если ты не укажешь переменную, то класс "повиснет"
> в памяти - его нельзя будет использовать или освободить
> "вручную"

тебе приведено 2 примера, прекрасно дополняющих твой ответ.
Имей силы принять поправки и не спорить против очевидного.

← →
Пусик © (2006-07-09 21:48) [19]

Примеры, подобные вышеуказанным, можно еще привести. Но зачем?
Ясно ведь, что, как правило, конструктор используется для создания объекта(кстати, - не компонента, заметь) и получения на него ссылки для дальнейшего использования.

Но существуют и другие объекты, управление которыми не требуется дополнительно. Пару примеров ты видел.

← →
DrPass © (2006-07-09 22:08) [20]

> tesseract © (09.07.06 21:33) [17]

Лучше не связывайся

← →
Пусик © (2006-07-09 22:12) [21]

> DrPass © (09.07.06 22:08) [20]

К нашим баранам в ветке в основной конференции мы еще вернемся. Вот только с работой немного посвободнее будет.

← →
DrPass © (2006-07-09 22:13) [22]

> Пусик © (09.07.06 22:12) [21]

ОК. Ты, кстати, на меня не обижайся - я живой человек и тоже могу вспылить :) Но поспорить люблю

← →
Пусик © (2006-07-09 22:15) [23]

> DrPass © (09.07.06 22:13) [22]
> > Пусик © (09.07.06 22:12) [21] ОК. Ты, кстати, на меня
> не обижайся - я живой человек и тоже могу вспылить :) Но
> поспорить люблю

Нет проблем. ;)

← →
tesseract © (2006-07-09 23:33) [24]

> тебе приведено 2 примера, прекрасно дополняющих твой ответ.
> Имей силы принять поправки и не спорить против очевидного.

Приведено два примера не общего порядка. Покажи где тут однозначно указано что указано что используется TWinControl. И где в Create значения передаются?

> Но существуют и другие объекты, управление которыми не требуется
> дополнительно. Пару примеров ты видел.

Как-раз таки это сделано, для поддержки визуального редактирования.

> Ясно ведь, что, как правило, конструктор используется для
> создания объекта

Т.е конструктор ещё для чего-то нужен бывает, кроме создяния объекта?

> имеет явный запах сказки.

Продемонстрируй у Tobject свойство parent. Оно есть только у TwinControl и ниже.
Про пример с TThread - вообще аут.

← →
Пусик © (2006-07-09 23:51) [25]

> Приведено два примера не общего порядка. Покажи где тут
> однозначно указано что указано что используется TWinControl.
> И где в Create значения передаются?

Про "общий порядок" - не поняла, что это такое.

Покажи где тут однозначно указано что используется TWinControl.
Это к чему? Причем здесь TWinControl? Ну передавай TObject, приведи к TWinControl, если угодно.

И где в Create значения передаются?

Например, здесь: TMyObj.Create(Form1,Form1);

> Т.е конструктор ещё для чего-то нужен бывает, кроме создяния
> объекта?

Конечно. Еще конструкор используется для инициализации полей, установки параметров при необходимости(в зависимолсти от различных условий).

> Продемонстрируй у Tobject свойство parent.

Зачем? Но если так хочется - пожалуйста:

TMyClass=class private FParent: TObject; public property Parent: TObject read FParent write FParent; end;

> Про пример с TThread - вообще аут.

Про это высказывание я бы пожестче сказала - бред.
Требовалось показать, что высказывание "Если ты не укажешь переменную, то класс "повиснет" в памяти - его нельзя будет использовать или освободить "вручную"." не совсем верно. И пример это демонстрирует в полной мере.

PS.

И все-таки, ответь: компонент, это объект или нет?

← →
tesseract © (2006-07-10 00:00) [26]

> Требовалось показать, что высказывание "Если ты не укажешь
> переменную, то класс "повиснет" в памяти - его нельзя будет
> использовать или освободить "вручную"." не совсем верно.

Оно верно абсолютно - ваши примеры - частные вырожденные случаи.

← →
Пусик © (2006-07-10 00:02) [27]

> tesseract © (10.07.06 00:00) [26]
> > Требовалось показать, что высказывание "Если ты не укажешь
> > переменную, то класс "повиснет" в памяти - его нельзя
> будет > использовать или освободить "вручную"." не совсем
> верно.Оно верно абсолютно - ваши примеры - частные вырожденные
> случаи.

Ну да, ну да. Вся рота идет не в ногу, один tesseract в ногу.

Счастливо оставаться в благостном (и воинственном) заблуждении.

← →
Zeqfreed © (2006-07-10 00:52) [28]

> [27] Пусик © (10.07.06 00:02)

Утверждение в [10] абсолютно верно. В ваших примерах, ссылка на объект, хотя и не явно, но сохраняется во внутреннем поле другого объекта. То, что вы демонстрируете является лишь удобной оберткой, предусмотренной разработчиками VCL. Разве не так?

> Zeqfreed © (10.07.06 00:52) [28]
> > [27] Пусик © (10.07.06 00:02)Утверждение в [10] абсолютно
> верно. В ваших примерах, ссылка на объект, хотя и не явно,
> но сохраняется во внутреннем поле другого объекта. То,
> что вы демонстрируете является лишь удобной оберткой, предусмотренной
> разработчиками VCL. Разве не так?

По пунктам:

Утверждение в [10] абсолютно верно.

Но не в полной мере. Почему? - см. [19].

В ваших примерах, ссылка на объект, хотя и не явно, но сохраняется во внутреннем поле другого объекта.

Почему бы ссылке не быть сохраненной?
Любой класс может включать в себя любые другие классы, ссылки на объекты дргого типа, поля любого типа.
Хочешь ввести ограничения?

То, что вы демонстрируете является лишь удобной оберткой, предусмотренной разработчиками VCL. Разве не так?

Все классы, возможные в ООП, есть удобные обертки для процедур, функций, переменных различного типа. И о чем это говорит?

-----------

Возвращаясь к Утверждение в [10] абсолютно верно., добавлю, что раз есть примеры, расширяющие утверждение, то это утверждение уже не абсолютно верно, а лишь частично. Для абсолютной верности ему не хватает верности во всех случаях.

> [29] Пусик © (10.07.06 01:43)

> Возвращаясь к Утверждение в [10] абсолютно верно., добавлю,
> что раз есть примеры, расширяющие утверждение, то это утверждение
> уже не абсолютно верно, а лишь частично. Для абсолютной
> верности ему не хватает верности во всех случаях.

Придется повториться: в ваших примерах ссылка на объект сохраняется. В [10] про такие случаи ничего не сказано, а сказано лишь про случаи, когда ссылка на объект не сохраняется.

> Zeqfreed © (10.07.06 01:50) [30]
>В [10] про
> такие случаи ничего не сказано, а сказано лишь про случаи,
> когда ссылка на объект не сохраняется.

А где ж ты увидел сохранение ссылки?

Разговор идет про конструкцию вида TMyClass.Create;
Именно такой пример и приведен. Разве не так?

> [31] Пусик © (10.07.06 01:53)

> [11] Пусик © (09.07.06 18:22)

> destructor TMyObj.Destroy;
> begin
> MessageBox(Application.Handle,"Однако, меня кто-то уничтожил!
> ","Хм...!",MB_OK);
> inherited;
> end;

Однако, этот кто-то и есть тот, кто сохранил ссылку. Истина где-то рядом. Как-то так, да?

В [10] сказано, что не сохранив ссылку на экземпляр класса, нельзя будет его уничтожить вручную. Вы же говорите, что это «необязательно». Не пожскажете код, который бы уничтожал объект, ссылка на который не была сохранена?

> Не пожскажете код, который бы уничтожал объект, ссылка
> на который не была сохранена?

Подскажу. И даже пример приведу. Только избавь меня от дальнейших бесполезных придирок?

Тот же самый класс, указанный выше. И к нему:

procedure TForm1.Button2Click(Sender: TObject); var i: Integer; begin for i := 0 to Form1.ComponentCount-1 do begin if (Form1.Components[i] is TMyLabel) then Form1.Components[i].Free; end; end;

> [33] Пусик © (10.07.06 02:19)

> Только избавь меня от дальнейших бесполезных придирок?

Ни за что на свете. Как же можно отказать женщине? Позвольте поинтересоваться, как возможно получить доступ к тому, чего нет? А ведь я просил пример, в котором ссылка не была бы нигде сохранена. И вы утверждаете, что данный код удовлетворяет этому малюсенькому условию. Так скажите же, как у вас получилось получить то, чего быть не должно? Наверное, виной всему природная женская магия… Ну что же, придется признать свое поражение.

← →
Шпиён (2006-07-10 02:38) [35]

> Zeqfreed © (10.07.06 02:25) [34]

Пример - завершение процесса -) Шутка

> Zeqfreed © (10.07.06 02:25) [34]

> Пусик © (10.07.06 02:19) [33]

Вам не кажется, что это уже просто флейм? -)

> А ведь я просил пример, в котором ссылка не была бы нигде
> сохранена.

А не надо просить того, что не существует.
Еще раз внимательно прочитай [10], начало ветки.
Обрати также внимание на конструкцию TMyClass.Create, которая не сохраняет ссылку на объект.

Разговора о том, что ссылка не будет сохранена вообще, не было. Поэтому не надо безосновательных претензий.

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

PS
А есть еще интерфейсы, COM.
И там это высказывание не только не будет абсолютно, но вообще верным.

Не все прямые дороги ведут к цели. То, что нельзя сделать шилом, можно штопором.

Что касается
конецформыначалоформы>MyClass.Create;
вспомним про КОЛ и про то, что там используется старая обьектная модель
TMyClass = object
...

Всё гораздо проще:)

> конецформыначалоформы>MyClass.Create;

MyClass.Create;

ООП - помогите разобраться. Найти похожие ветки