» Вопросы по Delphi (до версии 2009) - часть 6

SevereK20

Цитата:

нашел в cxTextEdit.pas ... но удивительно что не гуглится вообще... сочетание "cxTextEdit DoTextChanged" дает только 5 результатов... ито не то, что надо.

Недивительно, т.к. перекрывать такие защищенные методы, которые начинаются с Do - дурной тон

XPerformer
Это с чего вдруг дурной тон?????

SevereK20
Это правильный тон, не слушайте

salexn1
Если человек, способный разработать компонент такой сложности, сделал метод _защищенным_ - то есть поставил предохранитель, то видимо понимал, зачем он это делал. Если вы не понимаете, зачем нужны предохранители и никогда не слышали о технике безопасности, то ...

XPerformer
ок, тогда расскажите мне, как мне изменить отрисовку практически любого контрола из StdCtrls?

Давайте, чтобы Вам было легче, расскажите это на примере TLabel...

З.Ы. Чуть не забыл, протектед методы не трогайте только, на них же презерватив они с предохранителем

salexn1
Я тут не подвизался вас учить. Учеба денег стоит. Не можете обосновать свой совет - ну и ладно, мое дело предупредить новичка
А про презерватив - аналогия хорошая, и точка зрения на нее зависит от того, кому аборт делать.

XPerformer
Идите и учите мат часть тогда....
Protected методы созданы не для того, чтобы вешать на них "предохранители".
Сделаны они как раз для того, чтобы ТОЛЬКО НАСЛЕДНИКИ могли их переопределять.
А если уж и делать "предохранитель", то нужно делать их private...

В общем - в школу Вам и не путайте других

salexn1
Смысл создания наследника?

XPerformer
Изменить\добавить поведение "папочки"...


Цитата:

Я тут не подвизался вас учить. Учеба денег стоит.

Согласен.
Для решения данной задачи нужно, чтобы контрол умел себя отрисовывать разными цветами.
Он это умеет. Значит, его поведение менять не нужно. Нужно научиться им пользоваться в нужное время в нужном месте.
Создание наследника тут никаким боком.

XPerformer

После таких вот "советчиков" и говорят потом, что Дельфи для детей и нормальные проги писать нельзя на них...

Бегать по всем контролам и решать, как каждому контролу отрисовываться(Ваше предложение было) - это просто АХТУНГ!!! .

Потом это все разростается в нечитаемый и неподъемный код с кучей if - else. А если нужно на разных формах такое поведение - то вуаля - волшебный копи-паст спасает нас...

salexn1
Кажется, понял вашу идею.
На форме (или что еще хуже - на разных формах) лежат контролы разного типа - для ввода чисел, валюты, календарики и прочее. Для каждого из них переопределяем потомка, в котором прописываем одно и то же. При чем не факт, что переопределяемый метод есть у каждого типа контролов и называется при этом одинаково.
Видимо, это не подпадает под определение " нечитаемый и неподъемный код" с вашей точки зрения?
У меня по крайней мере все собрано в одной точке.

Цитата:

У меня по крайней мере все собрано в одной точке.

дык Вы ж сами сказали что в каждом контроле отрисовывать... какая же это одна точка?.

в процедуре OnTimer цикл пробегает по контролам, в котором case по типам и далее по обстоятельствам
Причем эту процедуру можно вынести в отдельный юнит и вызывать из разных форм
Универсальная штука получается
И если завтра надо будет по одному условию цвет менять, а по другому - мигать, а по третьему - бибикать, у меня есть одно место, где это дописать нужно будет

XPerformer
А если на одной форме, контролу нужно быть красным при <0, а на другой - синей - у вас это тоже будет предусмотрено...
if (FormName = 'Krasnaya') then ....

case по типам - это вааще ПЯТЬ балов!!!

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

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

ну а вообще, все началось с protected метода и Вы еще раз доказали, что вам пока
"УЧИТЬ МАТЧАСТЬ"

salexn1
Кто предок TColoredEdit?

XPerformer
В такой реализации не важно: сегодня один предок, завтра при необходимости можно заменить на другой. Правится в одном месте и больше нигде менять не нужно

salexn1
Тупо ходим по кругу - говорю же - у меня на форме УЖЕ есть несколько контролов разных типов - для ввода целых чисел, для ввода дробных чисел с копейками

XPerformer
минусы привязки на событиях есть такие - допустим вам надо поставить свой OnChange. Если вы его ставите в дизайнере, еще туда-сюда, можно запоминать перед присвоением общей процедуры старые обработчики и потом дергать их. Хуже, когда обработчик присваивается в рантайме, особенно если это делает другой программист, к-й не в курсе про автоприсваиваемые обработчики..

Ну и, как уже писал salexn1, архитектурно подход 'смешать все в кучу' плохой, в случае серьезных изменений начинается совершенно дикий case. Получается не 'универсальная штука', а полное барахло типа кейсов по формам (сиречь сильная связанность), где меняя одно условие, можно легко сломать другое.

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

Короче, во варианте с наследником меньше проблем в сопровождении.

зы:ну и насчет protected - не позорьтесь

A_V
Я не против наследников как таковых, вы не дослушали.
В делфи нет множественного наследования, это значит, следующего хода не будет. У контрола один наследник. Точка. Нужно объединить функциональность двух наследников с добавлением новой - тупик. Ваш подход тупо не рабочий, какая разница, насколько он эстетичен, соответствует вашим представлениям о правильности и т.п.

XPerformer
Нет никаких проблем, вы просто не умеете их готовить
Несколько разных вариантов поведения - не проблема - контрол перекрывает методы предкп, и дергает, в зависимости от надобности нужные методы внутренних классов.
Привидите конкретный пример, который не укладывается в этот подход

Я уже приводил.

Цитата:

у меня на форме УЖЕ есть несколько контролов разных типов - для ввода целых чисел, для ввода дробных чисел с копейками

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

зачем 2 потомка - то? или речь о разных контролах?
для одного контрола одного потомка достаточно.. со свойством -- как именно менять цвет. у у него может быть даже _отдельное_ событие (но не общее, как на OnChange), если хитро менять цвет нужно по разному у малого кол-ва контролов.
если бибикать будет хитро - тоже можно отдельно св-во..
короче, пусть контрол поддерживет все, что к нему конкретно относится, он может например реализовывать разные интерфейсы, и тогда по каждому контролу можно пройтись - и спросить - supports(IBeepable)? - тогда гуди.
где проблемы-то?

я понял - ключевое слово - интерфейсы. То есть будем решать проблемы по мере поступления. Нормально, правда, каша-малаша, отсутствие единой концепции как масштабировать продукт. В принципе, сойдет

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

Исходная задача - есть условие (программист читает - сегодня одно, завтра больше), которое может срабатывать извне. Надо раскрашивать контролы в два цвета (программист читает - реагировать = менять поведение, в том числе визуально перерисовывать контролы). Что тут такого что надо прямо заранее предусмотреть на все случаи жизни? Ну да, правильнее всего через интерфейсы или через сервисы, для тех кто знает с#. Но тот кто знает, тот тут такого уровня вопросы не задает. Мой ответ 1) расчитан на новичка, б) решает задачу, в) решает ее с некоторым запасом, на вырост. Поэтому в данных условиях мой ответ оптимален

Цитата:

Мой ответ 1) расчитан на новичка, б) решает задачу, в) решает ее с некоторым запасом, на вырост

согласен
с небольшой добавкой:
г)запас все-таки не очень большой
д)решение в духе порождать говнокод, для маленьких проектов, впринципе подходит, спору нет.

ну чей ответ оптимален, пусть считает автор, в конце-концов; речь сейчас вобще о 'правильном' подходе.

Добавлено:
XPerformer
на самом деле, то, что ты пытаешься показать - называется умным словом АОП, только с реализацией через ж..

A_V
Говнокод - вкусное слово, так и хочется его повторять, сам через это прохожу.

Но на самом деле, то что я пытаюсь показать, описано здесь
http://ru.wikipedia.org/wiki/Сервис-ориентированная_архитектура

Но грузить этим новичков не нужно, ибо - не понял и не поймешь, судя по всему, ибо - не хочешь

Добавлено:
извини, если погорячился с выводом, но просто уже не могу ждать, пока услышишь основную мысль

XPerformer
ага, я знаю карате, теквондо, и еще много страшных слов..

Основная твоя мысль в контексте топика, как я понял - есть у контролов события, на которых можно реализовать собственное поведение, не меняя сам контрол, значит так и надо делать. Это просто аспект работы с контролом, который привязывается сторонним образом (службой).

Моя мысль - нет, в таком виде, как ты описываешь, делать совсем не надо и сильно вредно и это порождает то самое 'вкусное слово' (особо памятуя, что в delphi нет multicast event'ов (вернее есть но через очень большую Ж)). Т.е наследник контрола в данном случае все равно быть должен. Подробно расписывать уже лень, и нужно это делать на нормальных примерах и с кодом.

XPerformer

Цитата:

В делфи нет множественного наследования

Не Ваш день сегодня... Причем здесь множественное наследование в принципе?!?!

1) расчитан на новичка...
судя по 'protected' фэйлу - это не на новичка, это в крови. Вы же упорно доказываете (и продолжаете это делать), что это не кашерно

2) решает задачу
тут согласен. сию минутную задачу да, но КРИВО, НЕ ЭФФЕКТИВНО ( и по скорости исполнения, и по реализации, и по поддержке)

3) насчет некоторого запаса
читай выше... НИКАКОГО запаса (кроме запаса гемора) в этом решении НЕТ


а вот это "Сервис-ориентированная архитектура" - лучше вообще удалите из поста!
Где вы у себя видели слабую связность????

Для 3 разных модулей с разной раскраской контролов Ваш код превратится в ТАКУЮ кашу, что Вы начнете просто плеваться от кода...

Сервис-ориентированная архитектура - если бы Вы предложили реализацию какого-то универсального интерфейса, который легко мог бы изменяться в зависимости от формы - я бы еще как-то с натяжкой сказал бы - YES!!! IT's TRUE!!!!

А так - ни о чем....

З.Ы. Ваш пример не говнокод (в прямом его смысле) - но где-то очень близко... Sorry!!!

salexn1
Цитата для тех, кто поленился пройти по ссылке выше:
"Главное, что отличает SOA, это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу."

Что имеем у нас:
1) событие 1 "Рак на горе свистнул" - сервис не знает, кто такой рак и как он свистит (и не стремится узнать)
2) реакция приложения "перекраситься" - выполняет сервис 1
3) реакция приложения "бибикнуть" - выполняет сервис 2
4) приложение дергает сервисы в нужный момент.
На делфи это можно организовать как некий цикл (типа оконной процедуры), который себе крутится и проверяет, а не свистнул ли рак, а не нажал ли юзер кнопку, а не 13-00, четверг ли сегодня и т.п.
Сервисы - реализовать как классы (синглетоны или нет), отдельные процедуры или как угодно.