Структурность vs Простота

← →
Kolan © (2007-07-26 15:33) [40]

> Опыт очень хорошее дело.

В смысле провести опыт, или всмысле опыт многих лет работы? Такие штуки с маленьким медиатором я последне время часто делаю&#133

← →
Игорь Шевченко © (2007-07-26 15:37) [41]

Kolan © (26.07.07 15:33) [40]

В смысле многих лет конечно. Когда начинаешь ценить простоту.

← →
Kolan © (2007-07-26 15:42) [42]

> Когда начинаешь ценить простоту.

Дык вы считаете перекрёсные ссылки пойдут?
Не, я согласен что для случая из сабжа(два объекта) пойдёт, но как только их станет три, я сделаю медиатор&#133
А вы?

ЗЫ
Надо же опыт перенимать :)

← →
Piter © (2007-07-26 15:50) [43]

Kolan © (26.07.07 14:57) [37]
Где сказано, что это хорошая практика?

а где сказано, что плохая?

Kolan © (26.07.07 14:57) [37]
Тогда гл. форма связана уже с 10 объектами, а в моём случае как был 1 медиатор, так и остался.

Зато все 10 форм связаны с медиатором. Не понял.
Опять же 10 связей.

Kolan © (26.07.07 14:57) [37]
В форме надо сделать метод MyShow(назание придумаете сами), который и будет снимать/устанавливать галочку

ага, ну офигеть. Это просто городить огород. Для такого элементарного действия придумывать такие ходы...

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

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

← →
Sandman29 © (2007-07-26 15:55) [44]

Игорь Шевченко © (26.07.07 15:37) [41]

Простота часто вступает в противоречие с удобством дальнейших изменений

← →
Игорь Шевченко © (2007-07-26 16:01) [45]

Kolan © (26.07.07 15:42) [42]

Я считаю, что в данном примере достаточно сделать Notification, потому что механизм оповещения срабатывает автоматически и никакого дополнительного кода для этого писать не надо.

Например:

unit main; interface uses Classes, Graphics, Controls, Forms, StdCtrls; type TfMain = class(TForm) CheckBox1: TCheckBox; procedure CheckBox1Click(Sender: TObject); public procedure Notification (AComponent: TComponent; AOperation: TOperation); override; end; var fMain: TfMain; implementation uses Child; {$R *.dfm} procedure TfMain.CheckBox1Click(Sender: TObject); var ChildForm: TComponent; begin if CheckBox1.Checked then with TfChild.Create(Self) do Show else begin ChildForm := FindComponent("fChild"); if Assigned(ChildForm) and not (csDestroying in ChildForm.ComponentState) then ChildForm.Free; end; end; procedure TfMain.Notification(AComponent: TComponent; AOperation: TOperation); begin inherited; if (AComponent.ClassName = "TfChild") and (AOperation = opRemove) then CheckBox1.Checked := false; end; end.

unit Child; interface uses Classes, Graphics, Controls, Forms; type TfChild = class(TForm) procedure FormClose(Sender: TObject; var Action: TCloseAction); end; implementation {$R *.dfm} procedure TfChild.FormClose(Sender: TObject; var Action: TCloseAction); begin Action := caFree; end; end.

Можно попробовать...

← →
Игорь Шевченко © (2007-07-26 16:02) [46]

Sandman29 © (26.07.07 15:55) [44]

> Простота часто вступает в противоречие с удобством дальнейших
> изменений

Никогда

← →
Kolan © (2007-07-26 16:19) [47]

> а где сказано, что плохая?

Во многих книгах/статьях, еще раз говорю это повышает связывание. Сильно связание объекты сами посебе  не проблемма вообще. Проблема возникает когда они изменяются.

Опять же 10 связей.
Вы не понимаете термин связывание. Прочтайте литаратуру, по сам паттерн хотябы&#133
Высокая степень связывания  когда объект зависит от большого числа других объектов.

Без медиатора форма зависит от 10 объектов.
С медиатором от одного.

В худщем случае, при вашем подходе, кажды объект будет связан с каждым. медиатор же разбивате эти связи. С медиатором каждый объект знает только медиатор.
То что сам медиатор будет свзан со всеми  нестрашно(это его предназначение по сути), так как он один, изменяется редко.

ага, ну офигеть. Это просто городить огород.
Я повторяю. если вы пишете фигню на 100 строк, то вы правы. Если вы пишете серьёзный(сложный) проект, то вы его в итоге провалите(хотябы по срокам).

Ну логично же?
Конечно логично, только:

> ты ему говоришь «если у тебя такая фигня случится  ты мне
> свистни»

А что будет если этих ТЫ не один а много, как тогда? В Delphi вы не подключитесь к одному событию несколькоми объектами.

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

Нет, не так.

Форма говорит медиатору: «Свести всем».

> с галочкой это уже перебор

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

Сделать перекрёсные ссыки  быстро только в начале, при добавлении новых, зависящих от галочи, объектов с медиатором вы сэкономите гораздо больше времени, чем потратите на его создание вначале.

← →
Kolan © (2007-07-26 16:21) [48]

> Я считаю, что в данном примере достаточно сделать Notification

Да ниче подход, согласен. Проще медиатора/наблюдателя и лучьше перекрёсных ссылок.

← →
Kolan © (2007-07-26 16:23) [49]

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

← →
Sandman29 © (2007-07-26 16:39) [50]

Игорь Шевченко © (26.07.07 16:02) [46]

Никогда

Проще скопировать, чем унаследовать, Вы не находите? Дальше продолжать?

← →
Игорь Шевченко © (2007-07-26 16:39) [51]

Kolan © (26.07.07 16:19) [47]

> Если вы спрашиваете про конкретный сабж с галочкой, то перебор.
> Я думаю вы хотите понят как делать это в более сложном
> случае. а галочка — это пример.

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

Хороший пример для демострации, правда, совсем иного, приведен у Мартина Фаулера в книге "Рефакторинг", в самом начале.

← →
Piter © (2007-07-26 16:43) [52]

Kolan © (26.07.07 16:19) [47]
С медиатором от одного

зато сам медиатор зависит от этих самых 10-ти форм!

Kolan © (26.07.07 16:19) [47]
То что сам медиатор будет свзан со всеми — нестрашно

Ну да. Если форма связана - это страшно, это нарушение паттерна и высокая степень связывания.

Когда медиатор связан - это не страшно, это фича!

Не вижу логики.

Kolan © (26.07.07 16:19) [47]
А что будет если этих ТЫ не один а много, как тогда? В Delphi вы не подключитесь к одному событию несколькоми объектами

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

AddListener(<ссылка на функцию>)
DeleteListener(<ссылка на функцию>)

А информацию о тех, кто требует уведомления - отлично хранить в TList

Kolan © (26.07.07 16:19) [47]
Я думаю вы хотите понят как делать это в более сложном случае

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

← →
Игорь Шевченко © (2007-07-26 16:46) [53]

Sandman29 © (26.07.07 16:39) [50]

> Проще скопировать, чем унаследовать, Вы не находите? Дальше
> продолжать?

Дружище, я имею в виду не простоту труда, а простоту реализации. Это две совершенно разные вещи.

Простота, а не легкость.

И, кстати, иногда проще (и легче) скопировать.

← →
Sandman29 © (2007-07-26 16:46) [54]

Piter © (26.07.07 16:43) [52]

Когда медиатор связан - это не страшно, это фича!

Не вижу логики.

Медиатор завязан на конкретное приложение, а каждую отдельную форму можно использвать где угодно.

← →
Sandman29 © (2007-07-26 16:49) [55]

Игорь Шевченко © (26.07.07 16:46) [53]

Что есть простота реализации?

← →
Kolan © (2007-07-26 16:52) [56]

> Когда медиатор связан  это не страшно, это фича!

Ну ты ленивый что ли? RTFM

Лана давай считать вместе. У тебя есть 10 объектов и все они должны быть связаы(по логике) друг с другом, сколько связей?
 Правильно 100.

Теперь с медиатором. Каждый объект связан с медиатором  10 связей. И медиатор знает всех  10 связей. Сколько всего?
Правильно 20.

Ок?

> А информацию о тех, кто требует уведомления  отлично хранить
> в TList

Ну вот вы и приближаетесь к «Наблюдателю».

> Просто интересно кто как на самом деле делает.

Вот чес слово, вот лично я делаю(не сделал бы, а делаю) медиатор.

← →
Игорь Шевченко © (2007-07-26 16:52) [57]

Sandman29 © (26.07.07 16:49) [55]

> Что есть простота реализации?

пост № 29:

"Существует одно простое правило, которого я стараюсь сам придерживаться и другим рекомендую:
Алгоритм программы должен быть реализован минимальным количеством ясных и понятных операторов."

← →
Kolan © (2007-07-26 16:57) [58]

> Еще раз (возвращаясь к вопросу о DataLayer и прочем):

Нет, это не тот случай. С DataLayer  согласен, на Delphi слишком много надо написать, чтобы работало&#133

> или галки с формой при реализации на Delphi просто бессмысленно.

Тут очень смысленно.

> Для простых вещей в Delphi, слава Аллаху, достаточно простых
> и опробованных методов, а всякие паттерны только собьют
> с толку.

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

> Хочется демостраций  их надо изучать на сложных примерах.

Мой поедены Ктулху мозг с трудом в простые примеры вникает, а вы про сложные&#133

> Хороший пример для демострации, правда, совсем иного

Про провалившейся проект?

← →
Игорь Шевченко © (2007-07-26 16:59) [59]

Kolan © (26.07.07 16:57) [58]

> > Хороший пример для демострации, правда, совсем иного
>
> Про провалившейся проект?

Я про пример из книги Фаулера "Рефакторинг". Фаулер не одну книгу написал.

← →
Kolan © (2007-07-26 17:01) [60]

> пост № 29:

Что-то я его проглядел.

> нечно, можно и GoF вооружаться.

Уверен что GoF знает большее кол-во людей чем VCL&#133

← →
Sandman29 © (2007-07-26 17:02) [61]

Игорь Шевченко © (26.07.07 16:52) [57]

Так я же и говорю - копирование. Куда уж минимальней и понятней.

← →
Kolan © (2007-07-26 17:03) [62]

> Я про пример из книги Фаулера «Рефакторинг».

Я про неёже и Говорю(Refactoring Improving the Designof Existing Code)&#133

Вы про это:
Once upon a time, a consultant made a visit to a development project. {&#133} Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance.

← →
Kolan © (2007-07-26 17:03) [63]

> Так я же и говорю  копирование.

Игорь Шевченко не об этом, имхо&#133

← →
Игорь Шевченко © (2007-07-26 17:05) [64]

Kolan © (26.07.07 17:03) [62]

> Once upon a time, a consultant made a visit to a development
> project.
> {…}
> Six months later the project failed, in large part because
> the code was too complex to debug or to tune to acceptable
> performance

Нет, я не про это. Я про пример с видеопрокатом, собственно, демонстрации рефакторинга.

← →
Kolan © (2007-07-26 17:08) [65]

> Нет, я не про это. Я про пример с видеопрокатом, собственно,
> демонстрации рефакторинга.

So I have to ask you to look at this and imagine it in the context of a much larger system.

Что я и пытаюсь сделать, и этого же про DataLayer хотел от вас&#133

← →
Sandman29 © (2007-07-26 17:16) [66]

Kolan © (26.07.07 17:03) [63]

А о чем? Может ты объяснишь?

← →
Игорь Шевченко © (2007-07-26 17:23) [67]

Kolan © (26.07.07 17:08) [65]

Я по русской книге смотрю, это глава 1.
Но даже тот пример, что приведен у Фаулера, это не таблица из двух бессмысленных полей (ID,Value), а вполне себе достаточный кусок кода.

Я, когда приобрел эту книгу (почти сразу, как появилась в России), смотрел на приведенный код и считал, что код, как код, многие так пишут, вполне себе. Потом, когда автор начал его корежить, я понял, в чем суть того, о чем дальше будет книга и мне это понравилось :)

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

← →
Kolan © (2007-07-26 17:31) [68]

> Я по русской книге смотрю, это глава 1.

Ну все правильно, после [65] Kolan © (26.07.07 17:08) в русской версии идут слова «исходная программа»

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

+1, только выходит что если я хочу вопрос задать(не понятно мне что-то) мне надо книгу написать, ну или пример листов на 100&#133
Ессно такой пример я не напишу, вот я и упрощаю.

Sandman29 © (26.07.07 16:46) [54]
Медиатор завязан на конкретное приложение, а каждую отдельную форму можно использвать где угодно

ага. Особенно там, где нет медиатора.

Не понял.

Kolan © (26.07.07 16:52) [56]
Лана давай считать вместе. У тебя есть 10 объектов и все они должны быть связаы(по логике)

это по какой такой логике интересной?! Если одна форма знает о двух других, это вообще не означает, что эти две формы знают друг о друге. В большинстве случае это и не так вовсе.

Игорь Шевченко © (26.07.07 16:52) [57]
Алгоритм программы должен быть реализован минимальным количеством ясных и понятных операторов

гы. Напрашивается логичное продолжение - "и, видимо, максимальным количеством неясных и непонятных операторов"

:)))))

Kolan © (26.07.07 17:01) [60]
Уверен что GoF знает большее кол-во людей чем VCL

но с другой стороны твой код скорее всего будет смотреть человек, который знает VCL, чем GoF

Kolan © (26.07.07 17:31) [68]

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

даже такой, как у Фаулера не напишешь ? Там не 100 листов, а от силы 2.

Книгу надо не писать, книгу надо читать.

Piter © (26.07.07 17:33) [69]

> Напрашивается логичное продолжение - "и, видимо, максимальным
> количеством неясных и непонятных операторов"

И такое случается. В этом случае автора программы обычно долго вспоминают нелестными словами. После его увольнения.

> Если одна форма знает о двух других, это вообще не означает,
> что эти две формы знают друг о друге.

Ты непробиваем, имхо это пройдет. Это пример, теория, которая часто подтверждается практикой&#133

Меняю свйо совет тебе(только в этом случае)  делай перекресные ссылки и не парься.

Sandman29 © (26.07.07 17:39) [72]
Как ты собираешься использовать форму, которая сама обращается к десятку других форм?

а такие главные формы из приложения в приложение и не переносятся, ибо очень индивидуальны. А вот например диалоговую формы настройки TCP/IP соединения вполне можно перенести, они никуда не обращается. В том числе она не обращается ни к какому медиатру.

А вот теперь объясни как ты собираешься использовать форму, если у тебя в другом приложении нету никакого медиатора?

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

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

В твоем случае она использует медиатор - значит надо рассматривать еще и медиатор. А медиатор использует главную форму, надо рассматривать еще и ее. Ну и где тут модульность?

Я понимаю смысл этого медиатора - это типа как диспетчер сообщений. Что-то навроде виндового диспетчера. Но наверное это нужно только в случае очень сложной иерархии.

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

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

> Piter © (26.07.07 17:58) [74]
> А вот теперь объясни как ты собираешься использовать форму,
> если у тебя в другом приложении нету никакого медиатора?
>
>

Дело обстоит приблизительно так, насколько я себе это представляю:

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

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

Sandman29 © (26.07.07 17:39) [72]

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

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

Bless © (26.07.07 18:08) [76]

похоже на мой вариант, только подписчиком у меня является сама форма, а не медиатор.

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

Мне моя версия кажется более логичной. Источник сам объявит - "я умею делать вот это", а уж другие у диспетчера могут спросить "а есть ли тот, кто может сделать это". Большая степень абстракции, диспетчеру не надо знать вообще о всех, кто может сделать то или иное. Так мне кажется логичнее, на этом принципе построена система плагинов в Miranda.

> Piter © (26.07.07 18:13) [78]

Я никоим образом не хотел твою версию принизить или опровергнуть.
Просто показал, что наличие/отсутствие медиатора никак не усложняет повторное использование формы и ответил на [74] (хоть ты и не меня спрашивал), не более того.

Bless © (26.07.07 18:26) [79]
Я никоим образом не хотел твою версию принизить или опровергнуть

дык я об этом и не говорил. Просто два разных подхода

Bless © (26.07.07 18:26) [79]
Просто показал, что наличие/отсутствие медиатора никак не усложняет повторное использование формы

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

А с регистрацией источника события и "клиентов" - это уже чуть другое.

Структурность vs Простота Найти похожие ветки