Какой смысл оформлять классы, не имеющие...

← →
ZeroDivide © (2006-12-13 09:42) [200]

> Изначально. Работа с объектом должна вестись через его свойства
> и методы. Навешивая снаружи что-либо на вложенные объекты
> мы можем нарушить работу внутренних механизмов. К тому же
> это ведет к ситуации, когда клиенты объекта завязаны на
> его внутреннюю реализацию.

Бред.

Работа с объектом должна вестись через его свойства и методы.

Она так и ведется. А то, что объект может обладать свойствами объектного типа - никоим образом инкапсуляцию не нарушает. И доступ к свойствам объекта вида Object.Property1.Property2.Event1 - вполне нормально для ООП.
Пример:
frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").AsInteger;
Или у вас это выглядит, как
frmGridView.FieldByName("ID").AsInteger;
:)
?

Навешивая снаружи что-либо на вложенные объекты
> мы можем нарушить работу внутренних механизмов.
Опять же, скорее наоборот: навешивая изнутри что-то мы можем нарушить работу предполагаемого поведения наших объектных пропертей. Хотя и в том и другом случае мы можем нарушить, а можем и не нарушить.
Пример: повесить обработчик события на вложенный компонент при инициализации фрейма, если при этом не написать код сохрания и вызова обработчика установленного разработчиком фрейма-потомка в инспекторе, то этот обработчик пойдет лесом... А если программер захочет повесить обработчик в рантайм? ... Тогда лесом пойдет обработчик, который повесил фрейм. В общем, как раз такое - делать нельзя!

>Сложные фреймы собираются в дизайнере из простых

Да... не лучшим образом.

1. На вложенных фреймах не будут работать наследники TComponentEditor
2.
>Связаны, в основном, с тем, как вложенность фреймов сохраняется в dfm.

3. Еще что-то... уже не помню (но есть)

Мы пришли к тому, что сделали из фреймов простое дерево, без вложенности веток друг в друга... в некоторых случаях пришлось пожертвовать уникальностью кода, копируя многие участки кода из одних веток этого дерева в другие, создавая в ветках повторяемые UI элементы...
Да, такую парадигму сделать и поддерживать, наверное сложнее... но только "трогать" базовые фреймы уже давно не приходится. Зато безглючность, гибкость, юзабельность вот этой получившейся основы - великолепная, куда выше чем была вкладывая фреймы друг в друга. Натуральный "Кирпичизм" получился: кода писать не надо, все возможные варианты интерфейса - уже написаны в базовых фреймах.
Остается писать бизнес-логику на стороне сервера... но это другая тема....

← →
Чапаев © (2006-12-13 10:03) [201]

> [199] Думкин © (13.12.06 06:21)
Ну, то была цитата. :-)

← →
Думкин © (2006-12-13 11:00) [202]

> Чапаев © (13.12.06 10:03) [201]

По стилю подачи - это не видно.

← →
Игорь Шевченко © (2006-12-13 11:06) [203]

ZeroDivide © (13.12.06 09:42) [200]

> > Изначально. Работа с объектом должна вестись через его
> свойства
> > и методы. Навешивая снаружи что-либо на вложенные объекты
>
> > мы можем нарушить работу внутренних механизмов. К тому
> же
> > это ведет к ситуации, когда клиенты объекта завязаны на
>
> > его внутреннюю реализацию.
>
>
> Бред.

Почему бред, не затруднит пояснить ?

← →
ZeroDivide © (2006-12-13 11:10) [204]

> Почему бред, не затруднит пояснить ?

А до конца дочитать пост?
(И еще перед эти желательно несколько постов.)

← →
Игорь Шевченко © (2006-12-13 11:13) [205]

ZeroDivide © (13.12.06 11:10) [204]

Я читать умею, спасибо. Но мне все-таки интересно, почему к процитированному относится слово "бред".

> Пример:
> frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").
> AsInteger;

Я как бы не согласен с таким вот нарушением инкапсуляции.

← →
vuk © (2006-12-13 11:40) [206]

to ZeroDivide © (13.12.06 09:42) [200]:
>Бред.
Ну-ну. :)

>А то, что объект может обладать свойствами объектного типа - никоим
>образом инкапсуляцию не нарушает.
И давно вложенные компоненты своствами стали?

>И доступ к свойствам объекта вида Object.Property1.Property2.Event1 -
>вполне нормально для ООП.
А вот это - действительно свойства. У Вас налицо путаница в понятиях компонентных свойств и вложенных компонентов.

>Или у вас это выглядит, как
>frmGridView.FieldByName("ID").AsInteger;
Нет, вот так мне точно в голову не придет написать. Если нужен доступ к данным к поля (редко), у фрейма делается свойство, с именем, совпадающим с именем поля и с типом данных, соответствующим реальному типу данных. И даже если нужно будет возвращать значение любого поля, то скорее будет свойство типа FieldValues[FieldName: string]:Variant, но никак не свойство, возвращающее ссылку на компонент. Ибо нефиг.

>На вложенных фреймах не будут работать наследники TComponentEditor
Неправда. Работают. Только, опять же, нужды в них нет.

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

← →
ZeroDivide © (2006-12-13 12:20) [207]

> И давно вложенные компоненты своствами стали?

Хорошо. Действительно, вложенные компоненты - поля. Доступ к полям, в том числе и объектных типов, может быть описан через read/write - через свойства. Вряд-ли вы не поняли, что я имел в виду и без уточнения в терминологии.

Но ни когда не задумывались, почему Borland сделал так, что при помещении компонента на фрейм поле добавляется в published, вместо того, чтобы кинуть его в protected и описать published property? Подумайте...

Если нужен доступ к данным к поля (редко), у фрейма делается свойство
И зачем?

Инкапсуляция (encapsulation) - это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый "чёрный ящик".

Вложенные компоненты - это published поля. Делая дополнительные свойства, вы просто сделаете более удобным доступ... но вряд ли он будет более наглядным (очень сомнительно, т.к. этот фрем может быть унаследован и dbGrid"ов и списков полей в наследнике может стать несколько) и с точки зрения защиты, подразумевающейся в инкапсуляции (я думаю вы как раз это имеете в виду под нарушением инкапсуляции), вы не сколько не защищаете, т.к. published.

← →
Игорь Шевченко © (2006-12-13 12:21) [208]

> Но ни когда не задумывались, почему Borland сделал так,
> что при помещении компонента на фрейм поле добавляется в
> published, вместо того, чтобы кинуть его в protected и описать
> published property? Подумайте...

Для загрузки значений свойств из dfm ? Я угадал и мне положен приз ?

← →
ZeroDivide © (2006-12-13 12:41) [209]

> Для загрузки значений свойств из dfm ? Я угадал и мне положен
> приз ?

Мог бы сделать загрузку protected полей из dfm, если бы помещал поля вложенных свойств в protected, но помещает все таки их в published. (Про RTTI я говорить не буду, но там тоже в таком случае можно было бы все грамотно разрулить).

... И все таки в published :)

Думаю основная возможность такой реализации заключалась в том, что объектные типы сами внутри себя защищены и прямое обращение к ним, если даже они объявлены в publised... не вызывает проблем защиты данных.

← →
vuk © (2006-12-13 12:42) [210]

to ZeroDivide © (13.12.06 12:20) [207]:
>Но ни когда не задумывались, почему Borland сделал так, что при
>помещении компонента на фрейм поле добавляется в published, вместо
>того, чтобы кинуть его в protected и описать published property?
>Подумайте...
Я не то чтобы задумывался. Я точно знаю зачем. Игорь уже сказал. :) Радикальное отличие компонентных свойств от published полей ещё и в том, что работа свойств как правило классами контролируется через методы доступа, а вот с published полями все не так.

>вы просто сделаете более удобным доступ...
В первую очередь я уменьшаю зацепление и отделяю интерфейс класса от реализации. А уже потом это становится удобным.

>и с точки зрения защиты, подразумевающейся в инкапсуляции вы не
>сколько не защищаете, т.к. published
Согласен здесь есть дыра, но я предпочитаю ей не пользоваться.

← →
Игорь Шевченко © (2006-12-13 12:44) [211]

ZeroDivide © (13.12.06 12:41) [209]

А ты ответь сам себе на вопрос - почему они не сделаны public

← →
vuk © (2006-12-13 12:47) [212]

to ZeroDivide © (13.12.06 12:41) [209]:
>Мог бы сделать загрузку protected полей из dfm
Мог бы, да не сделал. Реализация RTTI не позволяет. Ну лопухнулись чутка. :)

>прямое обращение к ним, если даже они объявлены в publised... не
>вызывает проблем защиты данных.
frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").Free;
Усё.

← →
DiamondShark © (2006-12-13 13:11) [213]

> Подобное есть, но до Borland"овского TFrame - не дотягивает.

Дотнетный UserControl дотягивает и перетягивает.

← →
ZeroDivide © (2006-12-13 13:17) [214]

frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").Free;
Усё.
?

Ну Button1.Free... и чего.. это не доказательство проблем защиты. Может я захотел кнопки поубивать... Почему бы и не поубивать что-нибудь у чего нет visible :)

>На вложенных фреймах не будут работать наследники TComponentEditor
Неправда. Работают. Только, опять же, нужды в них нет.

Сделай фрейм, положи в него TToolBar, положи этот фрейм в другой фрейм... и попробуй в дизайн-тайме на этом тулбаре вызвать "New Button"... получиться? :)

← →
ZeroDivide © (2006-12-13 13:20) [215]

> > Подобное есть, но до Borland"овского TFrame - не дотягивает.
>
>
> Дотнетный UserControl дотягивает и перетягивает.

Ну про "дотягивает" я уже писал. Я не нашел возможности реализовать с помощью UserControl, то что у меня реализовано с помощью TFrame. (Искал хорошо)

А про "перетягивает" хотел бы услышать подробнее...

← →
Ученик чародея © (2006-12-13 14:36) [216]

Удалено модератором

← →
Ученик чародея © (2006-12-13 14:39) [217]

> Юрий Зотов © (13.12.06 01:06) [194]
>
> Стандартное мнение тех, кто разглагольствут о том, чего
> не знает. Ничего нового.

Человек довольно грамотный Java программист, хотя в Delphi ничего не понимает, но берется сравнивать.

← →
Юрий Зотов © (2006-12-13 15:38) [218]

> Ученик чародея © (13.12.06 14:39) [217]

Это и имелось в виду. Очень много раз я слышал подобное мнение о Delphi от явистов, сишников и прочих - но моментально выяснялось, что судят они о том, чего практически не знают. И когда им рассказывали о том, что же такое Delphi на самом деле, то у них от удивления глаза на лоб лезли. Они, оказывается, раньше об этом и не подозревали.

В общем, сплошное "Мартышка и очки". Ничего нового.

← →
Юрий Зотов © (2006-12-13 15:52) [219]

> > Ученик чародея © (13.12.06 14:39) [217]

Кроме того, мне сильно не понравилось пальцегнутие. "Я писал на ассемблере, когда ты вообще еще учился писать" - и пр. Блин, очень может быть, что я писал напрямую в машкодах, когда этот парень еще даже и не родился - ну так и что? Я же не лезу рассуждать о том, о чем имею самое поверхностное представление.

И правильно его там в лужу посадили, когда он полный бред вспорол (что, мол, для невизуального компонента обязательно нужна форма, иначе его и положить некуда). А он, вместо того, чтобы тихо умыться и пойти читать книжки, наезжать на парня начал. Мол, да сколько лет ты пишешь, да имел ли дело с Delphi 1, да какие твои заслуги, если ты использовал кем-то написанный компонент - и пр. Блин, а ты использовал кем-то написанную DLL - ну и какие твои заслуги, чего ты пальцы-то гнешь?

Я не знаю, какой он явист, может и сильный, но в Delphi он полный чайник, а если еще учесть агрессивность и зазнайство - то законченный ламер.

Хотел ему все это там же и высказать, да регистрироваться влом было. Можете дать ему ссылку на этот пост, если тоже не лень.

← →
Чапаев © (2006-12-13 16:34) [220]

> И когда им рассказывали о том, что же такое Delphi на самом
> деле, то у них от удивления глаза на лоб лезли
Ух... Найти "явистов, сишников и прочих", способных выслушать "что же такое Delphi на самом деле" -- само по себе задача нетривиальная. ;-)

← →
Юрий Зотов © (2006-12-13 16:38) [221]

> Чапаев © (13.12.06 16:34) [220]

Не все, но иногда вменяемые люди все же встречались.

← →
Игорь Шевченко © (2006-12-13 16:52) [222]

Юрий Зотов © (13.12.06 16:38) [221]

> Не все, но иногда вменяемые люди все же встречались.

Повезло наверное

← →
Юрий Зотов © (2006-12-13 17:04) [223]

Кстати, обычно вменямыми оказывались именно те "сишники, явисты и пр". кто действительно разбирался в Си, Джаве, да и вообще в программировании.

А НЕвменямыми - именно те, кто, как постепенно выяснялось, ни в Си, ни в Джаве, да и вообще в программировании не шибко-то и рубили.

Зато как наезжали... как пальцы гнули... вот уж точно - ламеры.

← →
Игорь Шевченко © (2006-12-13 17:05) [224]

Юрий Зотов © (13.12.06 17:04) [223]

А наезжающих на С можно рассортировать ? Ну хотя бы по этому сайту

← →
Ega23 © (2006-12-13 17:14) [225]

> А наезжающих на С можно рассортировать ? Ну хотя бы по этому
> сайту

А точно также. Вменяемые на С не наезжают.

← →
Юрий Зотов © (2006-12-13 17:14) [226]

> Игорь Шевченко © (13.12.06 17:05) [224]

Не встречал, сортировать некого. Может, такие и были, но здесь их быстро на место ставят.

← →
vuk © (2006-12-13 17:25) [227]

to ZeroDivide © (13.12.06 13:17) [214]:
>Может я захотел кнопки поубивать... Почему бы и не поубивать что-нибудь
>у чего нет visible
Если по-нормальному делать, то фрейм сам должен прибивать то, чем владеет.

>Сделай фрейм, положи в него TToolBar, положи этот фрейм в другой
>фрейм... и попробуй в дизайн-тайме на этом тулбаре вызвать "New
>Button"... получиться? :)
То, что на внедренный фрейм нельзя добавлять компоненты не означает, что

> ZeroDivide © (13.12.06 09:42) [200]
> "На вложенных фреймах не будут работать наследники TComponentEditor"

← →
ZeroDivide © (2006-12-13 18:19) [228]

То, что на внедренный фрейм нельзя добавлять компоненты не означает, что
Да компоненты, не проблема... кинутый поверх внедренного фрейма визуальный компонент будет лежать как родной, хотя родной он будет, действительно, главному фрейму. А вот компонент-едиторы не работает... для моей парадигмы это критично...

Юрий Зотов © (13.12.06 17:14) [226]
Игорь Шевченко © (13.12.06 17:05) [224]

Дятьки старые... :)

Амбиции - это хорошо. Даже не подкрепленные знаниями, тоже хорошо. В их возрасте и с их опытом, они и не могут быть подкреплены. Вот научатся эти ламеры и тогда увидите... кто будет лучшими специалистами - те что с амбициями и претензиями или те, которые прогибаются.

to ZeroDivide © (13.12.06 18:19) [228]:
>А вот компонент-едиторы не
>работает...
Повторяю еще раз. Еще раз... Редакторы компонентов работают. Ра-бо-та-ют... Я проверял. Про-ве-рял...
:)

> ZeroDivide © (13.12.06 18:26) [229]

30 лет человеку. Профессиональный программист с немалым стажем.

Казалось бы, пора уже...

> Ра-бо-та-ют... Я проверял. Про-ве-рял...

И пример с ToolBar"ом п-р-о-в-е-р-я-л? :)

Юрий Зотов © (13.12.06 19:03) [231]
Профессиональный программист

Это вы про кого?? Про этого чтоли? http://skipy.dev.juga.ru/?philosophy/visualDesigners.html

Либо придется самому организовывать цикл обработки сообщений, что ничуть не проще

"Однако для того, чтобы использовать компоненту - нужна форма, на которую эту компоненту нужно положить. Иначе она выпадает из цикла событий приложения и неработоспособна." Ппц. Ещё б аффтар (модераторы, пардону просю!) объяснил какие такие "события приложения" сокету нужны...

> jack128 © (14.12.06 10:37) [233]

:-) Я смог дочитать только до слов "Однако для того, чтобы использовать компоненту - нужна форма, на которую эту компоненту нужно положить.", дальше читать не смог, разрыдался...
> ZeroDivide © (13.12.06 18:26) [229]

> Вот научатся эти ламеры и тогда увидите... кто будет лучшими
> специалистами

Они, обычно, становятся ламерами по продаже памперсов.

to ZeroDivide © (14.12.06 09:53) [232]:
>И пример с ToolBar"ом п-р-о-в-е-р-я-л? :)
Вам что, все по два раза нужно повторять? :)
У toolbar не работает по причине невозможности добавления компонентов на внедренный фрейм. Но это не означает, что редакторы компонентов не работают. Я же уже об этом написал в [227].

to Чапаев © (14.12.06 10:45) [234]:
>Ещё б аффтар (модераторы, пардону просю!) объяснил какие такие
>"события приложения" сокету нужны...
А вот нужны. Вы, кстати, исходники scktcomp.pas смотрели? И окно там скрытое есть, и обработка сообщений.

Вот тут нарисовали проблемку с вложеностью контроло
http://www.delphikingdom.ru/asp/answer.asp?IDAnswer=47625

Какие мысли?

Кстати, сабжевая статья, она в общем-то верная, если не считать очевидных ляпов автора и перекликается со статьей Павла Румянцева в покойном журнале "Программист"

"В последнее время наметилась одна тенденция. Дело в том, что сейчас для того, чтобы выйти на рынок программных средств и занять в нём свою нишу, фирма, а, соответственно, и программисты должны делать продукт как можно быстрее. При этом, естественно, достаточно часто вопросы эффективности, быстродействия, минимизации размера используемой памяти и тому подобные во внимание просто не принимаются. Зачем, дескать, думать о таких «мелочах», если современные компьютеры достаточно мощные и «переваривают» почти любые объёмы. Подумаешь, мегабайт памяти туда, мегабайт сюда… Кроме того, очень сильное влияние на квалификацию программистов оказывают многочисленные средства быстрой разработки, бурное развитие которых наблюдается в последнее время. Средства, предназначенные для повышения производительности труда квалифицированных программистов, заняли на рынке совершенно другое место. Достаточно часто эти средства используются программистами низкой квалификации для того, чтобы в кратчайшее время создать работающую программу, прикладывая при этом минимум усилий. Более того, средства быстрой разработки позволяют программисту скрыть недостаток квалификации, ибо вся черновая работа делается без участия программиста. Вместо того, чтобы овладеть необходимым для профессиональной деятельности минимумом, можно недостаток квалификации скрыть посредством использования программы, которая всё сделает сама. Таким образом, средства быстрой разработки используются превратились в средства создания неэффективных программ неквалифицированными программистами. Что поделаешь, рынок диктует свои условия…

Соответственно, такой подход приводит к тому, что достаточно часто у программистов появляется завышенная самооценка. Раз я могу «накропать» программу за неделю, значит, я – ВЕЛИКИЙ ПРОГРАММИСТ, всё умею, всё могу. Зачем мне чему-то учиться, я (при помощи конкретного средства) всегда сделаю то, что хочу! Появилось даже расхожее определение – «программист, пишущий мышкой»… Но стоит у подобных, с позволения сказать, программистов, забрать средство быстрой разработки, как они становятся беспомощными. Ведь они являются программистами на конкретном средстве! Другими словами, они являются ПОЛЬЗОВАТЕЛЯМИ конкретного средства… А пользователи и программисты – это совершенно различные классы людей, использующих компьютер в своей профессиональной деятельности. И если пользователю необходимо знать только порядок использования и взаимодействие частей одной или нескольких программ (WinWord, бухгалтерская или банковская программы, программа обработки изображений и так далее), то программист помимо всего прочего должен, почти обязан понимать то, как функционирует компьютер, на основе каких принципов построена операционная система, понимать принципы организации данных и быть в состоянии написать эффективную программу, решающую поставленную перед программистом задачу. В том случае, если программист является профессионалом, то использование средств быстрой разработки только поможет ему, позволив сократить время, необходимое для разработки программы, и минимизировать усилия, необходимые для разработки таковой. "

http://www.techbook.ru/rumyantsev.html

Гм... Действительно, наворотили там такого. Тем не менее, требовать форму для размещения компонента -- этог уж загнул.

Какой смысл оформлять классы, не имеющие... Найти похожие ветки