Здравствуйте, WolfHound, Вы писали:
WH>А сериализация с пропертигридом это уже детали реализации и их можно прицепить практически к любой модели.
Мне вобще непонятна попытка формулировать требования к архитектуре в терминах "шоб в пропертигриде показывалось", да еще вкупе с пространными теоретизированиями о слоях, модулях и идиотах-архитекторах.
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю в чьих переводах там упоминается зацепление, но в русскоязычном коммьюнити принят термин связность. AVK>Термин зацепление я от вас в первый раз слышу.
Значит, Вы не читали книгу Гради Буча, ибо там упоминаются и связность и зацепление:
"Термин зацепление взят из структурного проектирования, но в более вольном толковании он используется и в объектно-ориентированном проектировании. Стивенс, Майерс и Константайн определяют зацепление как "степень глубины связей между отдельными модулями. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями". <...>
Понятие связности также заимствовано из структурного проектирования. Связность — это степень взаимодействия между элементами отдельного модуля (а для OOD еще и отдельного класса или объекта), характеристика его насыщенности. <...> Наиболее желательной является функциональная связность, при которой все элементы класса или модуля тесно взаимодействую в достижении определенной цели." Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер. с англ. — М.: "Издательство Бином", СПб: "Невский диалект", 1998 г. — с. 139.
КЛ>>На счет инкапсуляции никто не спорит, а вот точка зрения о том, что бедный контракт — это хорошо, на мой взгляд, является неверной.
AVK>Взгляд будет подкреплен аргументами?
Да. В предыдущем сообщении я изложил свою точку зрения.
КЛ>>Т.е. полезно в одной компоненте группировать похожие функции, решающие однотипные задачи.
AVK>Это слишком примитивный взгляд на проблему. На практике, как всегда, все намного сложнее. Дело в том, что близость той или иной функции к другой вещь большей частью субъективная. Опять же, ровнять под одну гребенку разные ситуации нельзя. Вот к примеру метод Sort вробе бы как, на первый взгляд, неразрывно связан с коллекцией. Но, если мы сделаем его методом коллекции, нам придется реализовывать его в каждой коллекции по новой. Поэтому в данном случае более правильным было бы вынести метод Sort наружу. Тем самым мы уменьшаем сложность контракта IList, и упрощаем его реализацию. Теперь нам не надо реализовывать метод Sort в любой коллекции.
Вы, похоже, спорите сами с собой, приписываете мне утверждения, которые я не писал, а затем успешно опровергаете. Я же написал: Т.е. полезно в одной компоненте группировать похожие функции, решающие однотипные задачи.
Это означает, что берем все функции сортировки и группируем их в одну компоненту или один модуль Сортировщик, а не размазываем их по коллекциям. Точно также разные алгоритмы позиционирования контролов группируются в иерархию классов layout'ов. Можно привести и массу других примеров.
КЛ>>Наоборот, если в компоненту поместить функции, решающие разнотипные задачи, то получится несвязанный код и возникнет очень сильное зацепление. Зацепление будет сильным, т.к. к одной и той же компоненте придется обращаться для решения задач разных классов.
AVK>В общеупотребимых терминах это называется грамотная ОО декомпозиция. Только я то совсем о другом говорил.
Термин "грамотная ОО декомпозиция" звучит абстрактно и может использоваться разными собеседниками для обозначения совершенно разных решений разного качества.
Там, где возможно, лучше объясняться доходчиво и конкретно.
AVK>В том, о чем говорит WH не придется. А вот в предложенном тобой решении придется, потому что ты вынес все в базовый контракт.
Вы опять приписываете мне какие-то чужие решения.
КЛ>>Наследование — это инструмент реализации.
AVK>Ты внимательно прочел, что я написал?
Да, и объяснил, почему наследование интерфейса тоже относится к реализации. Если Вам непонятно, могу повторить еще раз, но другими словами.
Запись вида:
interface A {...};
interface B : A {...};
сделана на языке программирования, т.е. уже при помощи средства, предназначенного для реализации. При формулировании функциональных требований к компоненте и при написании контракта (т.е. прототипов функций) для компоненты никаких базовых и производных интерфейсов (в C# понимании) не существует. Это уж потом проектировщик решает вынести похожие функции в базовый интерфейс. А объявлять или не объявлять для групп одинаковых функций базовый интерфейс — это уже дело реализации (или очень позднего проектирования).
КЛ>>А, учитывая, что все применение наследования сводится к вынесению общих атрибутов в базовые классы
AVK>А как же полиморфизм?
КЛ>>, то во время анализа и на первых стадиях проектирования можно вообще успешно обойтись и без него.
AVK>Без наследования реализаций или без наследования контрактов?
КЛ>>Если же подойти с чисто практической точки зрения, то "наследование интерфейса" позволяет навесить одной компоненте несколько разных функциональностей.
AVK>Нет. Ты опять забыл про полиморфизм.
Так и полиморфизм тоже близок к реализации. Это лишь удобное средство унифицировать разные сущности языковыми средствами. В языках, которые не поддерживают полиморфизм, группировка осуществляется другими средствами. При этом функциональная модель (или, если хотите, контракт) модуля от этого не поменяется.
AVK>Мда. Вот я тебе честно скажу — я архитектора, который изъясняется подобным образом, сразу бы уволил. Куча текста ни о чем.
Давайте не будем переходить на личности и скатываться к неаргументированным оценкам. Поверьте, это от слабости.
AVK>Оно у тебя в твоем примере уже есть. Ты влепил в базовый контрол свойства, специфичные для конкретного лейаута. Завтра появится еще один, со своими свойствами, послезавтра еще один. И понеслась. В ходе эволюции интерфейс базового контрола раздуется. И что самое плохое — отрефакторить такой код будет весьма сложно, потому что на базовые контракты завязано, как правило, очень много кода (реализации).
Про лэйаут я уже объяснял несколько раз. Могу повторить еще раз: и в том, и в другом лэйауте используется прямоугольная сетка. Только в одном из них она состоит из пикселов, а в другом — из ячеек грида. Поэтому для всех прямоугольных "сеточных" лэйаутов такое обобщение может иметь место. И сколько бы прямоугольных "сеточных" лэйаутов ни появилось в будущем, все они уложатся в предложенную модель. Если Вы с этим не согласны, то приведите конкретный пример.
КЛ>> Потому что контракты определяются не атрибутами, а тем, как используется модуль.
AVK>Бред какой то. Контракты определяются требованиями. Атрибуты и методы это составляющие части ОО-контракта.
Вы опять спорите сами с собой. Почитайте, что написал я. Разве там написано что-то иное? Ведь требования к контролу как раз-таки и выделяются из сценариев его использования.
AVK>У тебя опять мешанина между наследованием реализаций и контрактов. Если атрибуты не находятся в публичных контрактах, то вынесение их в базовый класс и наследование этой реализации никоим образом не влияет на публичный контракт. Если же атрибуты изначально находятся в контрактах, то они в контрактах и остаются после выделения базового контракта.
Совсем нет — нет никакой мешанины. Наоборот, это Вы уцепились за модный термин "наследование контракта", и за этим термином не видите сути. Порочность в случае, о котором пишу я, заключается не в контрактах и реализациях, а в атрибутном подходе. Если человек берет за основу для классификации атрибуты, то он и наворотит похожим образом, что классы — что интерфейсы. А если при проектировании он навремя забудет про атрибуты и будет плясать от функционала (т.е. от того, как и для чего класс используется), то вопрос о группировке атрибутов отпадет сам собой или станет гораздо менее важным.
Например, Ваша иерархия прямоугольников и квадратов из обсуждения про прямоугольник и квадрат, является примером атрибутного подхода. На первый взгляд, все сделано умно и по-науке: есть контракты и есть реализации. Однако во главу группирования Вы поставили атрибуты, даже не поинтересовашись о том, нужны ли они.
Здравствуйте, AndrewVK, Вы писали:
AVK>PropertyGrid тут совсе не причем. То, что ты не можешь абстрагироваться от конкретных контролов при описании задачи не есть гуд.
Неумение объяснить суть задачи на доступном не для дот-нетчика уровне — гораздо хуже. Это говорит о неспособности абстрагироваться от языка или платформы реализации.
Здравствуйте, WolfHound, Вы писали:
WH>Это частности. Главное это вынесение из контрактов контролов то чего там быть не должно. WH>А сериализация с пропертигридом это уже детали реализации и их можно прицепить практически к любой модели.
Поверьте, это шаманство. Нужно изъясняться просто и доступно. Конечно, использование новомодных терминов по типу "вынесение из контрактов контролов" звучит круто и впечатляет. Но если мы уберем моднявые словечки и сформулируем суть задачи, которое сводится к доступности добавленных свойств в property grid'е и к сериализации кода инициализации этих свойств, то вся крутость как-то уйдет. И в сухом остатке окажется программерская задача 1-го уровня, которая потому и несложная, потому что .NET предоставляет все практически готовые решения.
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне вобще непонятна попытка формулировать требования к архитектуре в терминах "шоб в пропертигриде показывалось", да еще вкупе с пространными теоретизированиями о слоях, модулях и идиотах-архитекторах.
Не путайте требования к архитектуре с описанием условий задачи — суть разные вещи.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>И в сухом остатке окажется программерская задача 1-го уровня, которая потому и несложная, потому что .NET предоставляет все практически готовые решения.
И зачем только МС в WPF понадобилась новая компонентная модель?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Значит, Вы не читали книгу Гради Буча, ибо там упоминаются и связность и зацепление:
Читал. Но в оригинале, а не кривой перевод.
В Лингво, в компьютерном словаре, имеем такой перевод:
coupling
1) связь
2) соединение
3) связывание, увязка 4) связность (модулей системы)
Кстати, проглядывая русский перевод Буча, наткнулся на замечательную цитату:
… следует стремиться к тому, чтобы интерфейсная часть модулей была возможно более узкой (а пределах обеспечения необходимых связей). Наш стиль программирования требует скрыть все, что только возможно, в реализации модуля. Постепенный перенос описаний из реализации в интерфейсную часть гораздо менее опасен, чем "вычищение" избыточного интерфейсного кода. (читай — рефакторинг на бедных интерфейсах проще — прим. мое)
AVK>>Взгляд будет подкреплен аргументами? КЛ>Да. В предыдущем сообщении я изложил свою точку зрения.
Аргументов я там не увидел. Одни "я считаю".
AVK>>Это слишком примитивный взгляд на проблему. На практике, как всегда, все намного сложнее. Дело в том, что близость той или иной функции к другой вещь большей частью субъективная. Опять же, ровнять под одну гребенку разные ситуации нельзя. Вот к примеру метод Sort вробе бы как, на первый взгляд, неразрывно связан с коллекцией. Но, если мы сделаем его методом коллекции, нам придется реализовывать его в каждой коллекции по новой. Поэтому в данном случае более правильным было бы вынести метод Sort наружу. Тем самым мы уменьшаем сложность контракта IList, и упрощаем его реализацию. Теперь нам не надо реализовывать метод Sort в любой коллекции.
КЛ>Вы, похоже, спорите сами с собой, приписываете мне утверждения, которые я не писал
Например, в случае объектной модели полезно оценить количество интерфейсов и классов, приходящихся на одну сущность. Чем их больше, тем хуже.
Не ты писал?
AVK>>В общеупотребимых терминах это называется грамотная ОО декомпозиция. Только я то совсем о другом говорил.
КЛ>Термин "грамотная ОО декомпозиция" звучит абстрактно и может использоваться разными собеседниками для обозначения совершенно разных решений разного качества.
А зачем ты тут приводишь заведомо дурные решения? Тут их никто не предлагал, так что они только засоряют текст и делают понимание твоих мыслей крайне сложным.
AVK>>В том, о чем говорит WH не придется. А вот в предложенном тобой решении придется, потому что ты вынес все в базовый контракт.
КЛ>Вы опять приписываете мне какие-то чужие решения.
Топологическая модель может быть представлена структурами:
Визуальная модель может быть представлена набором таких записей:
ID.
Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
Text.
Picture.
Итого — мы имеем в базовом контроле Picture. На что тебе справедливо было замечено, что Picture имеет смысл только для некоторых видов контролов, отнюдь не для всех. В ответ ты написал:
WH>Да и некоторым контрола не нужны ни картинки ни текст.
При заполнении эти поля можно оставить пустыми.
Вот это и есть грубейшая ошибка проектирование, которая при эволюции приведет к такому геморою, что мало не покажется.
AVK>>Ты внимательно прочел, что я написал?
КЛ>Да, и объяснил, почему наследование интерфейса тоже относится к реализации.
Ты что то совсем другое объяснил. Куча текста не по теме про какие то высосанные из пальца дурацкие решения и 0 аргументов.
КЛ> Если Вам непонятно, могу повторить еще раз, но другими словами.
КЛ>Запись вида:
КЛ>
КЛ>interface A {...};
КЛ>interface B : A {...};
КЛ>
КЛ>сделана на языке программирования, т.е. уже при помощи средства, предназначенного для реализации.
Перепиши на UML. Что изменится? Или UML у тебя тоже реализацию описывает?
КЛ> При формулировании функциональных требований к компоненте и при написании контракта (т.е. прототипов функций) для компоненты никаких базовых и производных интерфейсов (в C# понимании) не существует.
Неправда. Внешние полиморфные алгоритмы требуют наследования контракта (если язык не поддерживает duck typing).
КЛ> Это уж потом проектировщик решает вынести похожие функции в базовый интерфейс.
Еще раз, внимательно послушай. Есть две принципиально разные вещи — наследование интерфейсов и наследование реализаций. Вот второе действительно сугубо реализационная фигня, применяемая, если мы обнаружили какую то общую часть, для избежания копипейста. А вот первое никакого отношения к реализации не имеет. Цепочка наследования интерфейсов является неотемлимой частью контракта. Именно поэтому в .NET запрещено наследование от классов и интерфейсов с меньшей видимостью. Именно поэтому в диаграммах UML присутствует отношение "is-a".
AVK>>Нет. Ты опять забыл про полиморфизм.
КЛ>Так и полиморфизм тоже близок к реализации.
Нет конечно. Это базовое свойство контрактов. На цепочку наследования контрактов полагается внешний по отношению к рассматриваемому коду код. Полиморфизм — базовое понятие в ОО-декомпозиции. Альтернативой ему в реально существующих языках может быть только duck typing.
КЛ>Давайте не будем переходить на личности и скатываться к неаргументированным оценкам. Поверьте, это от слабости.
Это не на личности, это по поводу того, что ты пишешь. Видишь ли, мне не платят за то, чтобы я прогребался в горах ненужной информации для вычленения небольшого количества слов по делу.
КЛ>Про лэйаут я уже объяснял несколько раз. Могу повторить еще раз: и в том, и в другом лэйауте используется прямоугольная сетка. Только в одном из них она состоит из пикселов, а в другом — из ячеек грида.
В Flow-лейауте сетки нет никакой.
КЛ> Поэтому для всех прямоугольных "сеточных" лэйаутов такое обобщение может иметь место.
А для остальных?
КЛ> И сколько бы прямоугольных "сеточных" лэйаутов ни появилось в будущем, все они уложатся в предложенную модель. Если Вы с этим не согласны, то приведите конкретный пример.
В WPFном Grid есть возможность для отдельных элементов управления задавать объединение ячеек.
Обрати внимание на то, как расположен лейбл с надписью. Где будем хранить информацию о таком финте ушами?
КЛ>>> Потому что контракты определяются не атрибутами, а тем, как используется модуль.
AVK>>Бред какой то. Контракты определяются требованиями. Атрибуты и методы это составляющие части ОО-контракта.
КЛ>Вы опять спорите сами с собой.
Это ты споришь непонятно с кем. Я освещал одну конкретную тему — принцип минимизации сложности контрактов. А ты в ответ успел поговорить обо всем. Ау. Ты не мысли свои спонтанным потоком сюда выливать должен, а общаться по конкретной теме.
КЛ>Совсем нет — нет никакой мешанины. Наоборот, это Вы уцепились за модный термин "наследование контракта"
Не знаю, с чего ты взял что это модный термин.
КЛ> Порочность в случае, о котором пишу я, заключается не в контрактах и реализациях, а в атрибутном подходе.
Вот, опять. Ну какого черта? О чем ты вобще говоришь? Если тебе о чем то хочется поговорить, это еще не означает, что остальным интересно слушать.
КЛ>Например, Ваша иерархия прямоугольников и квадратов из обсуждения про прямоугольник и квадрат, является примером атрибутного подхода.
Она является примером явной изоляции контракта и реализации.
КЛ> На первый взгляд, все сделано умно и по-науке: есть контракты и есть реализации. Однако во главу группирования Вы поставили атрибуты, даже не поинтересовашись о том, нужны ли они.
Это потому что ты не знаешь всей предыстории. Проблема квадратов и прямоугольников тут обсуждалась неоднократно, и основной парадокс, о который было сломано много копий, заключался в том, что с т.з. реализации квадрат не является наследником прямоугольника, а вот с точки зрения контракта является (речь, разумеется, об immutable классах). Как только мы разделяем два понятия, парадокс сам собой исчезает.
Здравствуйте, Кирилл Лебедев, Вы писали:
WH>>Это частности. Главное это вынесение из контрактов контролов то чего там быть не должно. WH>>А сериализация с пропертигридом это уже детали реализации и их можно прицепить практически к любой модели.
КЛ>Поверьте, это шаманство. Нужно изъясняться просто и доступно. Конечно, использование новомодных терминов по типу "вынесение из контрактов контролов" звучит круто и впечатляет. Но если мы уберем моднявые словечки и сформулируем суть задачи, которое сводится к доступности добавленных свойств в property grid'е и к сериализации кода инициализации этих свойств, то вся крутость как-то уйдет. И в сухом остатке окажется программерская задача 1-го уровня, которая потому и несложная, потому что .NET предоставляет все практически готовые решения.
Сколько пафоса... вот только толку нет.
1)Судя по всему ты так и не понял что такое присоедененные свойства и для чего они вобще понадобились.
2)На механизмы .NET эта задача не ложится. Да механизмы .NET несколько облегчают ее решение но не болие того.
3)Дался тебе этот проперти-грид. Сегодня он. Завтра что-то другое с другой моделью.
4).NET сериализация тут вобще работать не будет ибо есть требование десералировать в разнае реализации, а .NET так не умеет. Разве что можно попробовать XMLсериалайзером что-то сделать но и тут мы утыкаемся в отсутствие поддержки присоедененных свойств. Да и про то что сериализовать нужно куда попало тоже забывать не стоит.
ЗЫ И если уж проводить аналогию с той задачкой про мачты то тут не "Предположим, речное судно снабжено заваливающейся мачтой со стойкой длиной 6 м. На судне установили дополнительное палубное оборудование. Как теперь опускать стойку мачты, если свободного пространства (по горизонтали) осталось всего 3 м?", а "Предположим, речное судно снабжено заваливающейся мачтой со стойкой длиной 6 м. На судне непредсказуемым образом меняется конфигурация дополнительноого палубного оборудования. Как теперь опускать стойку мачты?"
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Кирилл Лебедев, Вы писали:
AVK>>PropertyGrid тут совсе не причем. То, что ты не можешь абстрагироваться от конкретных контролов при описании задачи не есть гуд. КЛ>Неумение объяснить суть задачи на доступном не для дот-нетчика уровне — гораздо хуже. Это говорит о неспособности абстрагироваться от языка или платформы реализации.
Это зацикливание на .НЕТ вобще и проперти-гриде в частности говорит о неспособности абстрагироваться от задачи.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>>На счет инкапсуляции никто не спорит, а вот точка зрения о том, что бедный контракт — это хорошо, на мой взгляд, является неверной. AVK>>Взгляд будет подкреплен аргументами? КЛ>Да. В предыдущем сообщении я изложил свою точку зрения.
Там было много слов. Но вот по сути сказано ничего небыло.
Так почему же бедные контракты это плохо не ясно.
AVK>>В том, о чем говорит WH не придется. А вот в предложенном тобой решении придется, потому что ты вынес все в базовый контракт. КЛ>Вы опять приписываете мне какие-то чужие решения.
Нет уж. Тут какраз совершенно точно твое творчество. Ибо твои таблички это и есть базовый, вернее единственный, контракт.
КЛ>сделана на языке программирования, т.е. уже при помощи средства, предназначенного для реализации.
В какой нотации записывать проектные решения значения не имеет.
Конечный язык программирования в этом случае ни чем не хуже других способов.
И даже лучше ибо потом не придется переписывать.
КЛ>При формулировании функциональных требований к компоненте и при написании контракта (т.е. прототипов функций) для компоненты никаких базовых и производных интерфейсов (в C# понимании) не существует.
Как не существует? А какже обобщение компонент?
В статически типизированных языках это можно сделать только выделением общих контрактов.
При описании функциональных требований ничего не формализированно. Те есть лишь описание типа такого: "Компонент кнопка. Должна генерировать событие при нажатии. Должна иметь надпись."
А вот при описании контрактов нам нужно уже все формализовать. Причем с учетом что кнопка она вобще не в вакууме находится, а есть еще множество других компонентов.
Вот тут и появляются базовае контракты.
КЛ>Это уж потом проектировщик решает вынести похожие функции в базовый интерфейс. А объявлять или не объявлять для групп одинаковых функций базовый интерфейс — это уже дело реализации (или очень позднего проектирования).
Вот кажется я начинаю понимать откуда ногу у твоих утверждений ростут.
Ты групируешь по принцпу "абы похоже было". Это не верный подход.
Нужно групировать не то что похоже, а то что логически принадлежит одной сущьности.
КЛ>Так и полиморфизм тоже близок к реализации. Это лишь удобное средство унифицировать разные сущности языковыми средствами. В языках, которые не поддерживают полиморфизм, группировка осуществляется другими средствами. При этом функциональная модель (или, если хотите, контракт) модуля от этого не поменяется.
На языках которые на примую не поддерживают полиморфизм его эмулируют.
AVK>>Мда. Вот я тебе честно скажу — я архитектора, который изъясняется подобным образом, сразу бы уволил. Куча текста ни о чем. КЛ>Давайте не будем переходить на личности и скатываться к неаргументированным оценкам. Поверьте, это от слабости.
А настойчивое требование проделать работу на пару человекомесяцев (этоя про подробное описание всех граблей скрещевания win с web) это надо пологать от силы?
КЛ>Про лэйаут я уже объяснял несколько раз. Могу повторить еще раз: и в том, и в другом лэйауте используется прямоугольная сетка. Только в одном из них она состоит из пикселов, а в другом — из ячеек грида. Поэтому для всех прямоугольных "сеточных" лэйаутов такое обобщение может иметь место. И сколько бы прямоугольных "сеточных" лэйаутов ни появилось в будущем, все они уложатся в предложенную модель. Если Вы с этим не согласны, то приведите конкретный пример.
В том то и дело что сеточных лейаутов может и не появиться. Те совсем.
Например тотже сплайн-лейаут. Ну ни разу не сеточный.
Да и лейаут с абсолютным позиционированием не обязын быть сеточным. Те там координаты и размеры могут быть во float'ах.
Скажем при рендере через DirectX это может быть очень даже востребовано.
КЛ>Совсем нет — нет никакой мешанины. Наоборот, это Вы уцепились за модный термин "наследование контракта", и за этим термином не видите сути. Порочность в случае, о котором пишу я, заключается не в контрактах и реализациях, а в атрибутном подходе. Если человек берет за основу для классификации атрибуты, то он и наворотит похожим образом, что классы — что интерфейсы.
Что таблички...
КЛ>А если при проектировании он навремя забудет про атрибуты и будет плясать от функционала (т.е. от того, как и для чего класс используется), то вопрос о группировке атрибутов отпадет сам собой или станет гораздо менее важным.
Группировака необходима. Без нее просто не сделать гибкую и расширяемую систему.
Те она не может быть не важной. Ибо она жизненно важна для дальнейшего развития системы.
А ели этому не уделять внимание то получится как у тебя... уж, еж, камаз и атомный ледокол свалены в одну кучу.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Кирилл Лебедев, Вы писали:
WH>>Тут есть только один человек который предлагает засунуть все свойства и все алгоритмы во все контролы КЛ>Мягко говоря, это не соответствует истине.
А кто кроме тебя предлагает тоже?
Визуальная модель может быть представлена набором таких записей:
ID.
Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
Text.
Picture.
Твое?
Вот скажи зачем edit'у картинка?
WH>>да еще и использовать одни и теже свойства для разных целей в зависимомти от фазы луны. И это не я. КЛ>Про layout'ы я Вам уже объяснял. Жаль, что Вы не поняли. Но ничего более добавить не могу.
Все я понял. Ибо у тебя там нет ничего кроме грубейших ошибок проектирования которые я просто обхожу на автопилоте. И объяснил почему эта модель не жизнесопособна. Жаль что ты ничего не понял... болие мне нечего сказать.
WH>>hint: Присоедененные свойства они на то и присоедененные что добавляются к компоненту внешними для этого компонента средствами, а не хардкодятся в сам компонент. КЛ>Просто непонятно, что Вы с этими свойствами делаете. Присоединяете ли Вы их лишь виртуально — только для того, чтобы они отображались в property grid вместе с другими свойствами контрола? Или Вы их каким-то образом динамически добавляете к другим свойствам контрола и, фактически, генерируете новый код? Или эти добавленные свойства сохраняются в XML вместе с другими свойствами контрола(т.е. "добавленные свойства" добавляются только для сохранения или только для сохранения и отображения в property grid).
Еще раз это все детали реализации. Это мелочи которые могут менятся как угодно.
Главное это то что в контрактах контролов остается только то что там должно быть и ничего больше.
Те если кнопка умеет нажиматься и показывать текст то она будет уметь только это и ничего больше.
Если сплайн-лейаут умеет выстраивать контролы вдоль некоторой кривой то в его контракте будет только то что нужно для того чтобы это обеспечить и ничего больше.
Такое разделение позволяет делать что угодно ибо нет ничего лишнего. Ничто не путается под ногами. Каждый контрол умеет только то что должен и ничего болие. Все просто, понятно и логично.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: О наследовании, иерархиях и проектировании (философское)
Прежде всего, хотелось бы поблагодарить Вас за интересный материал. Я некоторое время следил за Вашими попытками адаптировать ТРИЗ для разработки ПО и у меня сложилось впечатление, что определенные параллели есть. Хотелось бы лишь пожелать не относиться к этой задаче как к "цели всей жизни", поскольку практика (к сожалению, не только моя) показывает, что большинство красивых, многообещающих теорий в области разработки ПО рушатся при ударе об отвратительную действительность.
Если Вам все-таки удастся Ваша задумка, буду рад первым пожать Вашу руку, поскольку задача перед Вами стоит далеко не простая. Об этом далее.
2. Применение ТРИЗ к разработке ПО
Применить готовые наработки ТРИЗ к разработке ПО заманчиво, но этому может помешать ряд обстоятельств:
(по моим скромным данным) ТРИЗ изначально был предназначен для решения ИЗОБРЕТАТЕЛЬСКИХ задач в технике. Проблемная область технического изобретательства в чем-то похожа на область разработки ПО, но во многом от нее отличается, а именно:
— в технической изобретательской задаче мы имеем дело с более жесткими ограничениями, накладываемыми на техническое решение
— временные требования, предъявляемые к процессу решения технической изобретательской задачи как правило значительно более мягкие (так как основная затратная часть — это производство); аналогичная ситуация с денежными и прочими ресурсами
— сложность технических решений все же значительно ниже по сравнению с программными решениями, в которых, по известному замечанию Дейкстры, сознание человека вынуждено работать с размерностями от байта и до нескольких сотен мегабайт, что составляет разницу в 9 порядков (сейчас ситуация стала только хуже).
Если мы вспомним историю самого ТРИЗ, то г-н. Альтшуллер, разработчик теории, сетовал на то, что что изобретатели, даже самые сильные, работают неэффективным методом многочисленных проб и горестных ошибок. Т.е. в области технического изобретательства метод проб и ошибок (в т.ч. мозговой штурм) хотя и неэффективен, тем не менее является приемлемым способом решения практических задач. К сожалению, в разработке ПО никто даже и не думает о переборе вариантов, настолько их много.
Последний тезис, к сожалению, показывает не то, что теория г-на Альтшуллера была бы хорошо применима к разработке ПО. Наоборот он показывает, что разработка ПО существенно отличается от изобретательских технических задач, для которых разрабатывалась теория, и, хотя адаптация ТРИЗ была бы крайне ЖЕЛАТЕЛЬНА, возможности для такой адаптации остаются под вопросом.
Сам г-н. Альтшуллер приобрел определенный опыт в на ниве изобретательства, проанализировал немало готовых решений (в т.ч. из патентного бюро) перед тем, как сформулировать свою теорию. То есть, ему пришлось провести немалую работу по анализу предметной области.
Исключительно заманчиво было бы "сэкономить" время и силы, требующиеся на анализ предметной области разработки ПО за счет прямой адаптации принципов ТРИЗ, однако в силу вышеизложенных обстоятельств готового прямого пути для переноса идей ТРИЗ в область разработки ПО, по всей видимости, не существует.
Вам, по всей видимости, придется повторить путь методологов, таких как Грэйди Буч, г-н. Йордан, и в, определенном смысле, опыт г-на Альтшуллера по анализу предметной области перед тем, как удастся сформулировать теорию, базирующуюся на твердых фактах.
3. О конкретных принципах ТРИЗ
К сожалению, многие принципы ТРИЗ не могут быть применены к реальности разработчика ПО, о чем неоднократно заявляли участники форума.
Так, в частности, принцип идеальности системы критиковался с той позиции, что в разработке ПО как правило идеальная система не требуется, а требуется "достаточно хорошая", разработанная в приемлемые сроки, а главное — с учетом возможной дальнейшей модификации.
Далее, часто обсуждаемое положение ТРИЗ (которое по сути является одним из подпунктов понятия идеальной системы) — положение о том, что разрабатываемая система должна быть как можно меньше физически. Справедливая критика указывала на то, что физически минимальные системы трудно понимать, сопровождать, к тому же они не всегда являются оптимальными с точки зрения, например, скорости исполнения.
Лично я бы хотел усомниться в целесообразности разбиения решаемой предметной области на классы по принципу функциональности, как это предлагаете Вы. Мне хотелось бы обсудить с Вами этот вопрос, поэтому об этом подробнее.
В классической методологии объектно-ориентированного моделирования (OMT) предлагается разработать словарь предметной области, который и будет являться базой для разработки классов и установления отношений между ними. Вы предлагаете радикально противоположный подход — разбивать задачу исходя из сиюминутных требований к конкретному программному модулю. Хотя, быть может, Ваш подход дает видимый сиюминутный выигрыш, мне кажется что при росте требований, предъявляемых к системе, Ваша модель классов будет справляться с ними хуже, чем менее элегантная (с точки зрения текущей задачи) модель, основанная на словаре предметной области.
4. Касательно структуры Вашего доклада
Несомненно, область в которой Вы работаете (а именно, перенос ТРИЗ в разработку ПО) проработана мало, а потому нет ни устоявшейся терминологии (хуже того, есть терминология, отличная от устоявшейся), ни общепринятых фактов и исследований, на которые можно было бы опереться. Говоря иными словами, Вы только вступили на обширную почву для исследований и потому трудно ожидать материалов, соответствующих всем нормам и формам, принятым в технической литературе.
Злую шутку сыграл так же и тот факт, что Вы смогли предоставить лишь презентацию доклада, а сам доклад (в Вашем изложении) остался за кадром. Отсюда большое количество (обоснованных, в общем-то) вопросов и непонимания со стороны участников форума.
Несмотря на вышеизложенные факты, я считаю доклад интересным и благодарю Вас за то, что Вы не побоялись предоставить его на суд общественности.
5. Заключение
В заключении хотелось бы еще раз пожелать Вам творческих успехов. Несомненно, если Вам удастся продвинуться хотя бы на несколько шагов дальше в избранном Вами направлении, все только выиграют.
Re[2]: О наследовании, иерархиях и проектировании (философск
в общей сложности разобрано 14 задач. Еще две сквозные задачи были подготовлены для презентации. Но из-за необходимости ограничить объем выступления была изложена только одна. Таким образом, все выводы делаются только на основе практических примеров. Конечно, найденные закономерности сопоставляются с закономерностями и методами классической ТРИЗ. Но механического переноса нет.
B>В классической методологии объектно-ориентированного моделирования (OMT) предлагается разработать словарь предметной области, который и будет являться базой для разработки классов и установления отношений между ними. Вы предлагаете радикально противоположный подход — разбивать задачу исходя из сиюминутных требований к конкретному программному модулю. Хотя, быть может, Ваш подход дает видимый сиюминутный выигрыш, мне кажется что при росте требований, предъявляемых к системе, Ваша модель классов будет справляться с ними хуже, чем менее элегантная (с точки зрения текущей задачи) модель, основанная на словаре предметной области.
Нет сомнения, что словарь предметной области — вещь полезная, и отказываться от него, думаю, не стоит. Однако использование словаря в качестве основы для проектирования модулей и классов порождает, к сожалению, архитектуры, не устойчивые к изменениям. В этом легко убедиться на примерах, изложенных в книгах по OOA и OOD. В одной из наших статей были разобраны две задачи из книги Гради Буча. На этих примерах были наглядно показаны недостатки объектного (или, если хотите, словарного) подхода. Если на Ваш взгляд, примеры выглядят неубедительно, Вы можете предложить какую-нибудь другую задачу — я готов ее разобрать. Но разбор потребует совместно работы.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Это слишком примитивный взгляд на проблему. На практике, как всегда, все намного сложнее. Дело в том, что близость той или иной функции к другой вещь большей частью субъективная. Опять же, ровнять под одну гребенку разные ситуации нельзя. Вот к примеру метод Sort вробе бы как, на первый взгляд, неразрывно связан с коллекцией. Но, если мы сделаем его методом коллекции, нам придется реализовывать его в каждой коллекции по новой. Поэтому в данном случае более правильным было бы вынести метод Sort наружу. Тем самым мы уменьшаем сложность контракта IList, и упрощаем его реализацию. Теперь нам не надо реализовывать метод Sort в любой коллекции.
КЛ>>Вы, похоже, спорите сами с собой, приписываете мне утверждения, которые я не писал
AVK>
Например, в случае объектной модели полезно оценить количество интерфейсов и классов, приходящихся на одну сущность. Чем их больше, тем хуже.
AVK>Не ты писал?
Вообще, в данном случае лучше всего взглянуть в абстрактную теорию. Ведь не одним Гради она ограничевается. А абстрактная теория описывает 7 типов связывности модулей(подчеркиваю, речь идет о модулях). Приводятся в порядке, от худшей сопровождаемости, до лучшей.
1. Связность по совпадению. В модуле отсутсвуют явно выраженные внутренние связи.
2. Логическая связность. Части модуля объединены по принципу функционального подобия. Например, модуль состоит из разных подпрограмм обработки ошибок. При использовании такого модуля клиент выбирает только одну из подпрограмм.
Недостатки:
* сложное сопряжение
* большая вероятность внесения ошибок при изменении сопряжения ради одной из функций.
3. Временная связность. Части модуля не связаны, но необходимы в один и тот же период работы системы.
4. Процедурная связность. Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения.
5. Коммуникативная связность. Части модуля связаны по данным(работают с одной и той же структурой данных).
6. Информационная (последовательная) связность. Выходные данные одной части используются как входные данные в другой части модуля.
7. Функциональная связность. Части модуля вместе реализуют одну функцию.
(c) С.А. Орлов Технологии разработки программного обеспечения. Разработка сложных программных систем.
Из данной классификации, можно сделать однозначный вывод, что хотя полной функциональную связность сделать невозможно, но чем меньше интерфейс, тем более он сопровождабельный.(также заметим, что логич. связность не очень хорошая связность). Там же еще был показан весьма правильный график:
Фактически, сверхгранулярность в виде функциональной связности — сильно увеличивает стоимость.
Однако все это теория. На практике, гранулярность определяется эвристически, без всяких методик, согласно своему опыту. Я вполне допускаю что обойтись без такого
Здравствуйте, WolfHound, Вы писали:
WH>Так почему же бедные контракты это плохо не ясно.
Во-первых, я не говорил, будто бедные контракты — это плохо. Я лишь заметил, что Вы никак не аргументировали Ваше утверждение. Т.е. из Вашего сообщения никак не вытекает прямая связь между бедностью контракта и слабым зацеплением и расширенностью контракта и сильным зацеплением.
Например, на практике я часто видел бедные контракты, которые не то что трудно было как-то повторно использовать, но и текущие задачи они довольно-таки плохо решали — из-за своей бедности. Причина сильного зацепления кроется не в богатости или бедности контракта, а в смешивании разнородных функций в одном модуле. Т.е. глупо создавать коллекцию, в которую помещаются различные методы сортировки и/или группировки элементов, работающие по разным алгоритмам. Глупо потому, что при создании какой-либо другой коллекции эти методы нужно повторять и в ней тоже.
Если же модуль выполняет набор однотипных функций (например, сортирует все, что подадут ему на вход), то богатый контракт будет не в минус, а в плюс, т.к. он позволит задавать параметры выполняемых функций (например, алгоритмы сортировки). Т.е. контракты могут быть богатыми (широкими), но в рамках одной функциональной группы.
WH>Нет уж. Тут какраз совершенно точно твое творчество. Ибо твои таблички это и есть базовый, вернее единственный, контракт.
Тут Вы ошибаетесь. Таблички относятся к реализации. А вот выделение в процессе создания формы различных операций, под каждую из которых и можно потом заточить структуры данных — это и есть суть решения. Это и есть базовый контракт.
WH>В какой нотации записывать проектные решения значения не имеет. WH>Конечный язык программирования в этом случае ни чем не хуже других способов. WH>И даже лучше ибо потом не придется переписывать.
При описании проектных решений конкретный язык программирования лучше использовать лишь для иллюстрации некоторых решений или для прослеживания модели. Если же проектировать в терминах языка, то есть риск (причем довольно существенный) построить модель, сильно привязанную к конкретной реализации. Что автоматически означает, что при необходимости поменять реализацию придется и переделать модель.
Для иллюстрации приведу пример-аналог: не смотря на то, что программа компилируется в набор нулей и единиц, глупо проектировать в "нулях" и "единицах" (или даже в ассемблерных командах).
КЛ>>При формулировании функциональных требований к компоненте и при написании контракта (т.е. прототипов функций) для компоненты никаких базовых и производных интерфейсов (в C# понимании) не существует. WH>Как не существует? А какже обобщение компонент? WH>В статически типизированных языках это можно сделать только выделением общих контрактов.
Вы путаете обобщение с наследованием. Наследование — всего лишь удобный инструмент. Например, в C++ при помощи template'ов я могу написать обобщенный алгоритм, который будет работать с разными типами данных. Разумеется, эти типы данных должны поддерживать определенный интерфейс. Но для них совершенно не нужно объявлять базовый абстрактный класс (или interface).
WH>Вот кажется я начинаю понимать откуда ногу у твоих утверждений ростут. WH>Ты групируешь по принцпу "абы похоже было". Это не верный подход.
С тем, что такой подход неверен, я согласен. Но практикуете его Вы, а не я. Вы же отстаиваете здесь правильность атрибутного наследования. Да еще и некоторые идеологи ООП во главе с Бучем и Рамбо.
WH>Нужно групировать не то что похоже, а то что логически принадлежит одной сущьности.
Что значит "логически принадлежит"? Каковы критерии "логичной принадлежности"?
WH>На языках которые на примую не поддерживают полиморфизм его эмулируют.
Вы опять зациклились на полиморфизме. Действительно, его можно эмулировать. Но можно и совсем не использовать. Например, можно написать отдельную реализацию для каждого сеточного layout'а. А можно обойтись и одной реализацией, т.к. по сути дела нет никакой разницы (для алгоритма) между ячейкой-пикселем и ячейкой грида.
WH>А настойчивое требование проделать работу на пару человекомесяцев (этоя про подробное описание всех граблей скрещевания win с web) это надо пологать от силы?
Не думаю, что составление списка из двух-трех проблем займет пару человекомесяцев. Полагаю, что эта работа на 10 — 15 минут для человека, который с этими проблемами уже сталкивался и их как-то решал.
WH>В том то и дело что сеточных лейаутов может и не появиться. Те совсем. WH>Например тотже сплайн-лейаут. Ну ни разу не сеточный. WH>Да и лейаут с абсолютным позиционированием не обязын быть сеточным. Те там координаты и размеры могут быть во float'ах. WH>Скажем при рендере через DirectX это может быть очень даже востребовано.
Но я-то говорю о сеточных лэйаутах. Хотя, при желании, и все остальные лэйауты можно свести к одному виду. Тут главное — не лениться и не возмущаться, что все лэйауты — разные, и что их невозможно скрестить.
WH>Группировака необходима. Без нее просто не сделать гибкую и расширяемую систему. WH>Те она не может быть не важной. Ибо она жизненно важна для дальнейшего развития системы. WH>А ели этому не уделять внимание то получится как у тебя... уж, еж, камаз и атомный ледокол свалены в одну кучу.
Группировка, конечно, необходима. Тут спору нет. Только начинать ее нужно не с атрибутов, а с функций. И группировать нужно не просто так, а в соответствии с решаемыми задачами. Т.е. для решения других задач для той же самой предметной области группировка может быть совсем другой. А так получается, что вы выделяете атрибуты и группируете их, еще даже не определившись с тем, для чего, собственно говоря, Вы это делаете.
Сравните две модели:
Модель-1. Программист мыслит: "Вот есть объект. У объекта есть такой и такой атрибуты. Вот — другой объект. У него тоже есть атрибуты. Некоторые атрибуты объекта-1 и объекта-2 совпадают. Значит вынесу-ка я их базовый класс. И т.д."
Модель-2. Программист мыслит: "Согласно спецификации программа должна помогать пользователю решать такие-то и такие-то задачи. Для решения задачи-1 нужно выполнить такой-то набор действий. Для решения задачи-2 нужно выполнить другой набор действий. Эти действия можно распределить по группам. Одна группа отвечает за такой набор функций, другая — за другой, третья — за третий. Каждую группу можно представить в виде отдельной подсистемы, отдельного модуля или класса. Эта подсистема должна поддерживать такой-то интерфейс. Подсистеме передаются на вход такие-то и сякие-то объекты. Чтобы упростить реализацию подсистемы, эти объекты должны поддерживать одинаковый интерфейс. Если объектов немного и времени мало, унифицируем объекты при помощи полиморфизма. Если объектов много, то пытаемся унифицировать их не только на уровне интерфейса, но и на уровне реализации, как с сеточными layout'ами".
Здравствуйте, WolfHound, Вы писали:
WH>Твое?
Это относится к реализации, а не к интерфейсу. И продемонстрировано лишь для иллюстрации. А вот интерфейс заключается в выделении последовательности операций, которые система должна выполнить для того, чтобы создать и отобразить форму.
Собственно, об этом я уже писал выше не один раз. Но Вы продолжаете повторять одно и то же, как заклинание, не обращая внимание на мои слова. То ли не понимаете, то ли считаете, что от пустого повторения станет очевиднее Ваша правота.
WH>Вот скажи зачем edit'у картинка?
А зачем edit'у список дочерних окон? Или почему окну без заголовка можно установить caption? И еще много "почему" можно задать по поводу Win32.
Тем не менее, Win32 API стал стандартом и достаточно долго использовался разработчиками прикладных программ.
WH>Все я понял. Ибо у тебя там нет ничего кроме грубейших ошибок проектирования которые я просто обхожу на автопилоте. И объяснил почему эта модель не жизнесопособна. Жаль что ты ничего не понял... болие мне нечего сказать.
Вы поете дифирамбы себе и продолжаете бездоказательно утверждать, что у меня там где-то есть "грубейшие ошибки". Между тем, от того, что Вы повторите словосочетание "грубейшие ошибки" сотню раз, грубейшие ошибки не обнаружатся. И обычный повтор не снимет с Вас бремя доказательства Вашего тезиса.
Кроме того, обратите внимание, что Вы так по-человечески и не описали Вашу задачу — так, чтобы программист, не программирующий на .NET, мог ее понять. От конкретизации Вы уклоняетесь, ссылаясь на абстрагирование. От описания конкретных проблем скрещивания Win с Web тоже уклоняетесь, ссылаясь на месяцы работы.
КЛ>>Просто непонятно, что Вы с этими свойствами делаете. Присоединяете ли Вы их лишь виртуально — только для того, чтобы они отображались в property grid вместе с другими свойствами контрола? Или Вы их каким-то образом динамически добавляете к другим свойствам контрола и, фактически, генерируете новый код? Или эти добавленные свойства сохраняются в XML вместе с другими свойствами контрола(т.е. "добавленные свойства" добавляются только для сохранения или только для сохранения и отображения в property grid). WH>Еще раз это все детали реализации. Это мелочи которые могут менятся как угодно.
Это не детали реализации. Это все относится к сути задачи и к спецификации, которую Вы, как технический специалист, должны уметь писать.
WH>Главное это то что в контрактах контролов остается только то что там должно быть и ничего больше.
Контракты — это уже результат проектирования. Контракты нужны для решения задачи. В условиях, когда задача не определена и не поставлена, бесполезно обсуждать правильность или неправимльность, полезность или бесполезность того или иного контракта.
WH>>Вот скажи зачем edit'у картинка? КЛ>А зачем edit'у список дочерних окон? Или почему окну без заголовка можно установить caption? И еще много "почему" можно задать по поводу Win32.
КЛ>Тем не менее, Win32 API стал стандартом и достаточно долго использовался разработчиками прикладных программ.
Мало ли какое фуфло стало стандартом. Вон, каменный топор стал стандартом в каменном веке, и использовался очень долго — уж по сравнению с Win32 API так точно. Предлагаете использовать его наряду с современными инструментами по этой причине?
Оправдывать кривизну дизайна тем что "так сделано в широкораспространённой системе XXX, и ничего — живёт как-то" — это вопиющий непрофессионализм.
КЛ> Причина сильного зацепления кроется не в богатости или бедности контракта, а в смешивании разнородных функций в одном модуле.
И в том и в другом. Точнее так, чем богаче контракт, тем больше вероятность того, что в одном классе смешали разнородные функции.
Чем богаче контракт — тем сильнее связность, это азбука. Нам что, хором тебя в этом убеждать?
Не веришь нам, почитай классиков:
...
We've now seen that a reasonable way to gauge the amount of encapsulation in a class is to count the number of functions that might be broken if the class's implementation changes. That being the case, it becomes clear that a class with n member functions is more encapsulated than a class with n+1 member functions.
Scott Meyers
Если класс имеет много функций-членов, которые не обязаны быть членами, но тем не менее являются таковыми (таким образом обес-
печивается излишняя видимость закрытой реализации) [читай — "богатый" контракт, прим. мое], то закрытые члены-данные класса становятся почти столь же плохими с точки зрения дизайна, как и открытые переменные.
Функции, не являющиеся членами или друзьями классов, повышают степень инкапсуляции путем снижения зависимостей: тело такой функции не может зависеть от закрытых и защищенных членов класса. Они также разрушают монолитность классов, снижая связность, и повышают степень обобщенности....
Саттер, Александреску.
КЛ>Если же модуль выполняет набор однотипных функций (например, сортирует все, что подадут ему на вход), то богатый контракт будет не в минус, а в плюс, т.к. он позволит задавать параметры выполняемых функций (например, алгоритмы сортировки). Т.е. контракты могут быть богатыми (широкими), но в рамках одной функциональной группы.
Опять все смешалось...
Алгоритм сортировки — это реализация, она не может быть частью этого контракта. Логика простая: шире контракт => больше методов придется менять при изменении реализации => большая связность. Эта логика работает всегда, как правило буравчика.
Допустим у нас есть огромный класс с десятком различных реализаций сортировки: При появлении нового метода нам придется менять существующий класс, вместо того, чтобы написать еще одну реализацию в новом классе => больше вероятность сломать существующий код. Очень высокая вероятность того, что один алгоритм неявно завяжется на другой (приватные данные общие) => при изменении одной реализации мы сломаем другую, ect...
Так что там в плюс?
КЛ>Мне кажется, что модель-2 гораздо продуктивнее.
Обе уродские.
.png)
А абстрактная теория описывает 7 типов связывности модулей(подчеркиваю, речь идет о модулях). Приводятся в порядке, от худшей сопровождаемости, до лучшей.
Мы уже победили, просто это еще не так заметно...
