Здравствуйте, Кирилл Лебедев, Вы писали:

WH>>Так почему же бедные контракты это плохо не ясно.
КЛ>Во-первых, я не говорил, будто бедные контракты — это плохо. Я лишь заметил, что Вы никак не аргументировали Ваше утверждение. Т.е. из Вашего сообщения никак не вытекает прямая связь между бедностью контракта и слабым зацеплением и расширенностью контракта и сильным зацеплением.
Так ты же все игнорируешь...
Можешь еще раз перечитать пост AVK
Re[29]: О сопровождении

Автор: AndrewVK
Дата: 02.06.07

WH>>Нет уж. Тут какраз совершенно точно твое творчество. Ибо твои таблички это и есть базовый, вернее единственный, контракт.
КЛ>Тут Вы ошибаетесь. Таблички относятся к реализации. А вот выделение в процессе создания формы различных операций, под каждую из которых и можно потом заточить структуры данных — это и есть суть решения. Это и есть базовый контракт.

Невозможно качественно спроектировать систему в отрыве от реализации.
Тут есть множество факторов.
1)Архитектура системы зависит от языка на котором ее будет писать. (В болие правильном случае используемый язык зависит от выбранных архитектурных решений.)
2)Есть требования которые нельзя сформулировать до того как система будет хотябы частично написана.
Дело в том что большие программы имеют настолько большое колличество возможных реализаций что сесть и просчитать все варианты не может никто.
По этому приходится постоянно заниматься исследованиями и на их основе уточнять требования.
А после уточнения требований нужно менять уже написанный код.
По этому системы должны быть не минимальны, а устойчивы к изменениям.

КЛ>При описании проектных решений конкретный язык программирования лучше использовать лишь для иллюстрации некоторых решений или для прослеживания модели. Если же проектировать в терминах языка, то есть риск (причем довольно существенный) построить модель, сильно привязанную к конкретной реализации. Что автоматически означает, что при необходимости поменять реализацию придется и переделать модель.
Еще раз.
Без привязки к языку качественно спроектировать систему нельзя.
Ибо даже в случае C++ и C# эффективные архитектурные решения будут совершенно различны. Те просто ничего общего.
И перевод системы с одного языка на другой подразумевает не только полное переписывание но и полную переработку архитектуры.
А если вспомнить про болие другие языки (lisp, erlang...) то там решения будут еще болие другими.

Теперь что касается модели и реализации.
Контракты они на то и формализуются чтобы можно было менять реализацию частей системы не затрагивая другие части.

КЛ>Для иллюстрации приведу пример-аналог: не смотря на то, что программа компилируется в набор нулей и единиц, глупо проектировать в "нулях" и "единицах" (или даже в ассемблерных командах).
Это не тот форум где проходит демагогия.

КЛ>Вы путаете обобщение с наследованием. Наследование — всего лишь удобный инструмент. Например, в C++ при помощи template'ов я могу написать обобщенный алгоритм, который будет работать с разными типами данных. Разумеется, эти типы данных должны поддерживать определенный интерфейс. Но для них совершенно не нужно объявлять базовый абстрактный класс (или interface).
Основное требование а компоненте это связывание во время работы программы.
Есдинственный способ связать что-то с чем-то в сатически типизированном языке это интерфейсы.
Кстати интерфейсы не наследуют. Ибо наследовать там физически нечего. Их реализуют.

КЛ>С тем, что такой подход неверен, я согласен. Но практикуете его Вы, а не я. Вы же отстаиваете здесь правильность атрибутного наследования. Да еще и некоторые идеологи ООП во главе с Бучем и Рамбо.
Я?! Разве это я свалил все контролы и лейауты в одну кучу?
Болие того наследование я вобще применяю очень редко.
Я формализую интерфейсы и реализую их.

КЛ>Что значит "логически принадлежит"? Каковы критерии "логичной принадлежности"?
Такие вопросы ставят меня просто в тупик.
Я перестаю понимать на каком уровне с тобой общаться.

КЛ>Вы опять зациклились на полиморфизме. Действительно, его можно эмулировать. Но можно и совсем не использовать.
Без него у тебя небудет никакого связывания во время исполнения программы.

КЛ>Например, можно написать отдельную реализацию для каждого сеточного layout'а. А можно обойтись и одной реализацией, т.к. по сути дела нет никакой разницы (для алгоритма) между ячейкой-пикселем и ячейкой грида.
Дело в том что нет никаких сеточных лейаутов.
Единственный лейаут который можно назвать сеточным это грид.
А что касается пикселей то их в общем случае нет.
При рендере через D3D или на векторном устройстве у тебя нет никаких пикселей.
И если векторные устройства в данный момент не актуальны то рендер через D3D или OGL очень даже востребован.
Хотя если учесть то что экраны с большим колличеством точек на дюйм при сохранении растра не реализуймы... просто столько данных не прокачать... ну сам посчитай поток 6000*8000*3(а то и 6 байт на пиксель)*100(кадров в секунду)

КЛ>Не думаю, что составление списка из двух-трех проблем займет пару человекомесяцев. Полагаю, что эта работа на 10 — 15 минут для человека, который с этими проблемами уже сталкивался и их как-то решал.
Это я уже делал. Но ты отмахнулся.

КЛ>Но я-то говорю о сеточных лэйаутах.
Ты можешь говорить о чем угодно.
Но то что лейауты должны быть не только сеточные те один грид никто не отменял.

КЛ>Хотя, при желании, и все остальные лэйауты можно свести к одному виду. Тут главное — не лениться и не возмущаться, что все лэйауты — разные, и что их невозможно скрестить.
Это как ты собрался скрестить грид со сплайном?
При том что у них нет ничего общего кроме коллекции контролов положением которых они рулят.
Объясни пожалуйста.

КЛ>Группировка, конечно, необходима. Тут спору нет. Только начинать ее нужно не с атрибутов, а с функций.
Так я и начинаю.
Болие того по другому и не группирую.

КЛ>И группировать нужно не просто так, а в соответствии с решаемыми задачами. Т.е. для решения других задач для той же самой предметной области группировка может быть совсем другой. А так получается, что вы выделяете атрибуты и группируете их, еще даже не определившись с тем, для чего, собственно говоря, Вы это делаете.
Это ты сам придумал.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Это относится к реализации, а не к интерфейсу.
Интерфейс без реализаци не стоит ничего.
И фигня в том что какой интерфейс такая и реализация.
А раз реализация дерьмо то и интерфейс не лучше.
Ибо для того чтобы плохо реализовать качественно спроектированные интерфейсы нужно приложить большие усилия.
А раз у тебя легко получилась пожалуй худшая (можно еще хуже но это уже очень сложно) из возможных реализаций...

КЛ>И продемонстрировано лишь для иллюстрации.
За такие иллюстрации увольняют сразу.
Болие того если ты у меня на собеседовании человек с опытом предложит подобную реализацию то собеседование на этом будет окончено со словами: "Извините вы нам не подходите." + Занесение в черный список кандидатов до скончания времен.
Причем в случае с зеленым студентом еще можно подумать и позадовать вопросы быть может он это сморозил просто по неопытности и его можно относительно быстро переучить.
Но если человек во время своей практики не понял к чему приводит такое то тут уже ничего не поможет.

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

КЛ>Собственно, об этом я уже писал выше не один раз. Но Вы продолжаете повторять одно и то же, как заклинание, не обращая внимание на мои слова. То ли не понимаете, то ли считаете, что от пустого повторения станет очевиднее Ваша правота.
Тебе я могу сказать тоже самое.

КЛ>А зачем edit'у список дочерних окон? Или почему окну без заголовка можно установить caption? И еще много "почему" можно задать по поводу Win32.
Ссылка на авторитеты. Причем весьма сомнительные.
С демагогией в другой форум пожалуста.

КЛ>Тем не менее, Win32 API стал стандартом и достаточно долго использовался разработчиками прикладных программ.
Он еще долго будет использоваться.
Только к делу это отношение не имеет.
Кстати сам мелкософт признал ущербность окнной системы виндов.

КЛ>Вы поете дифирамбы себе и продолжаете бездоказательно утверждать, что у меня там где-то есть "грубейшие ошибки". Между тем, от того, что Вы повторите словосочетание "грубейшие ошибки" сотню раз, грубейшие ошибки не обнаружатся. И обычный повтор не снимет с Вас бремя доказательства Вашего тезиса.
Так я на них уже не однократно указывал.
Вот только каждый раз была мантра: Все в порядке. Все в порядке. Все в порядке.

КЛ>Кроме того, обратите внимание, что Вы так по-человечески и не описали Вашу задачу — так, чтобы программист, не программирующий на .NET, мог ее понять.
А причем тут вобще .НЕТ?
Это всеголишь одна из возможных платформ для реализации.

КЛ>От конкретизации Вы уклоняетесь, ссылаясь на абстрагирование. От описания конкретных проблем скрещивания Win с Web тоже уклоняетесь, ссылаясь на месяцы работы.
Если ты не можешь вывести хотябы самые большие из них исходя из того факта что системы принципиально различные...

WH>>Еще раз это все детали реализации. Это мелочи которые могут менятся как угодно.
КЛ>Это не детали реализации. Это все относится к сути задачи и к спецификации, которую Вы, как технический специалист, должны уметь писать.
Кому должен?

Заказчика это не интересует.
Ему интересно какие там будут формочки и иногда с какой скоростью оно будет работать (если конечно скорость не ниже плинтуса).
Он вобще посмотрит на меня как на идиота (и будет прав) если я проезнесу слова "присоедененные свойства".
Ему нужно чтобы система была быстро, качественно и дешево написана и также быстро, качественно и дешево поддерживалась.
За это он готов платить бабло. Вернее за уменьшение собственных издержек.
А архитектурные изыски нужны мне чтобы снизить мои издержки.
И особенно важной становится архитектура когда заказчиков много и все они хотят странного.

Или ты про описание собственно деталей реализации чтобы другие могли разобраться?

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

ID.
Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
Text.
Picture.

Ибо это никакия не формализация, а сплошное шаманство.

Здравствуйте, IB, Вы писали:

IB>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.
IB>[/q]
IB>Scott Meyers

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

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

IB>[q]
IB>Если класс имеет много функций-членов, которые не обязаны быть членами, но тем не менее являются таковыми (таким образом обес-
IB>печивается излишняя видимость закрытой реализации) [читай — "богатый" контракт, прим. мое], то закрытые члены-данные класса становятся почти столь же плохими с точки зрения дизайна, как и открытые переменные.

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

IB>Опять все смешалось...
Что смешалось? Разве алгоритм сортировки не может быть указан в качестве параметра? Почему? Хочет пользователь отсортировать массив quicksort'ом — указывает один параметр, а хочет отсортировать пузырьком — указывает другой параметр. В чем Вы видите проблему?

IB>Алгоритм сортировки — это реализация, она не может быть частью этого контракта. Логика простая: шире контракт => больше методов придется менять при изменении реализации => большая связность. Эта логика работает всегда, как правило буравчика.

Вы хотели написать, что тем выше "зацепление"? Это не так. Если Вы обратитесь к источникам, которые я приводил выше (Гради Буч, Тимати Бадд), то увидите, что зацепление характеризует зависимость между модулями, а не между интерфейсом (контрактом) и его реализацией. Поэтому количество функций в контракте не играет никакой роли. Страшно изменение не реализации, а интерфейса: сколько модулей придется изменить при изменении интерфейса? Очевидно, что таких модулей будет тем больше, чем больше разнородных функций выполняет изменяемый модуль. Хотя бы потому, что к этому модулю обращаются совсем по разным поводам.

IB>Допустим у нас есть огромный класс с десятком различных реализаций сортировки: При появлении нового метода нам придется менять существующий класс, вместо того, чтобы написать еще одну реализацию в новом классе => больше вероятность сломать существующий код. Очень высокая вероятность того, что один алгоритм неявно завяжется на другой (приватные данные общие) => при изменении одной реализации мы сломаем другую, ect...
IB>Так что там в плюс?
Никакого не вижу плюса. Но почему Вы решили, будто я советую поместить все функции сортировки в отдельный класс? Модуль — это не только класс (во всяком случаее, в C++). Если Вы проследите за сообщениями, то увидите, что я сторонник отделения того, что сортируют от того, чем сортируют. Т.е. есть различные коллекции, а есть сортирвщики, которые эти коллекции сортируют. При этом, необходимо, чтобы все коллекции поддерживали бы единый интерфейс для сортировки.

КЛ>>Мне кажется, что модель-2 гораздо продуктивнее.
IB>Обе уродские.
А аргументы? Поверьте, банальное шапкозакидательство без аргументации на профессиональном форуме для инженеров как-то не катит.

Здравствуйте, WolfHound, Вы писали:

WH>Интерфейс без реализаци не стоит ничего.
Странно слышать это от человека, который ратует за абстрагирование.

WH>За такие иллюстрации увольняют сразу.
WH>Болие того если ты у меня на собеседовании человек с опытом предложит подобную реализацию то собеседование на этом будет окончено со словами: "Извините вы нам не подходите." + Занесение в черный список кандидатов до скончания времен.
WH>Причем в случае с зеленым студентом еще можно подумать и позадовать вопросы быть может он это сморозил просто по неопытности и его можно относительно быстро переучить.
WH>Но если человек во время своей практики не понял к чему приводит такое то тут уже ничего не поможет.

А у нас в компании на собеседовании принят иной подход. Если я с решением не согласен, но человек — может его обосновать, то почему бы и нет? Даже если он ошибается, видно, что человек думает и не ленится работать. В том числе, приучен решать сложные задачи.

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

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

Например, если на вопрос: "С какими задачами Вы сталкивались при унификации win и web forms?" Кандидат отвечает: "Это сложная задача. На описание потребуется 2 человекомесяца", то мы сразу с ним прощаемся. Потому что велика вероятность, что он шаманит. Т.е. профессионализм Кандидата проверяется на сложных и кропотливых задачах. При этом важно не столько правильность решения, сколько подход к выполнению работы и терпение.

Здравствуйте, Кирилл Лебедев, Вы писали:

WH>>Интерфейс без реализаци не стоит ничего.
КЛ>Странно слышать это от человека, который ратует за абстрагирование.
А все остальное как всегда проигнорировал.
Я даже не удивлен.

КЛ>А у нас в компании на собеседовании принят иной подход. Если я с решением не согласен, но человек — может его обосновать, то почему бы и нет? Даже если он ошибается, видно, что человек думает и не ленится работать. В том числе, приучен решать сложные задачи.
Так ты же не можешь...

КЛ>В конце-концов, научить такого человека другому подходу — дело времени, при чем совсем небольшого.
А... ну-ну...

КЛ>Это гораздо дешевле, чем искать "звезду"
В конторе где я сейчас работаю в основном звезды.
Скорость с которой контора развивается подавляющему большинству контор и не снилась...

КЛ>или брать на работу человека, который умеет говорить "правильные" слова в соответствии с ООП-книгами, но не может решить конкретной задачи.
Это ты про себя?
Ведь это ты заладил про нарушение LSP в совершенно простом и безграбельном коде.
А если ты посмотришь не то как пишут компиляторы на нормальных языках то у тебя волосы дыбом встанут ибо там такие нарушения происходят в массовом колличестве.
И это не только не приводит к проблемам но и позволяет значительно упростить и удешивить разработку. Раз эдак в 10 относительно С++...

КЛ>Например, если на вопрос: "С какими задачами Вы сталкивались при унификации win и web forms?" Кандидат отвечает: "Это сложная задача. На описание потребуется 2 человекомесяца", то мы сразу с ним прощаемся. Потому что велика вероятность, что он шаманит. Т.е. профессионализм Кандидата проверяется на сложных и кропотливых задачах. При этом важно не столько правильность решения, сколько подход к выполнению работы и терпение.
А я тебе сразу сказал с чем столкнулся. Главная засада из которой прямо или косвенно растут все остальные это фундаментально разные принципы работы этих платформ. Любой спец знакомый в общих чертах с win и web (а тех кто совсем не знаком пожалуй нет) легко выведет кучу очевидных проблем (о них я тоже говорил). Ну еще не нужно забывать про кучу не очевидных заботливо раскиданных меокософтом, w3c и производителями браузеров.
Вот только ты счел это слишкм абстрактным и стал требовать деталей.
А их в этой задачи столько что...
Причем парой деталей от тебя не отделаться. Ибо ты тут же предложешь решение которое учитывает только эти детали. Надеюсь не нужно объяснять почему это не приемлемо.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Майерс поменял местами причину со следствием.

Аргументы? Поверь, банальное шапкозакидательство без аргументации на профессиональном форуме для инженеров как-то не катит. (С)
Видишь ли, человечество за долгое время своего существования, выработало хороший подход к решению задач. Если получается формаизовать условие и решение, то можно выработать методику, позволяющую решать все однотипные задачки. В данном случае, проблема в том, что "монолитность", сама по себе формализации не поддается, а вот степень "бедности" контракта — очень хороший формальный критерий, который практически напрямую указывает на степень "монолитности". У того же Меерса этому посвящено довольно много.
Таким образом, "обедняя" контракт мы уменьшаем "монолитность", что в свою очередь, уменьшает связность и увеличивает гибкость и удобство поддержки, чего, собственно, и добивались.

КЛ>Точный критерий зацепления формулируется иначе:
Точный критерий связности, формулируется именно так, как указано у Мейерса, Саттера и Александреску, а так же МакКонела и кучи других ребят. Цитату я уже приводил — "чем больше функций придется менять при изменении реализации — тем выше связность". Других критериев связности нет.

КЛ> Обширность интерфейса в рамках группы однородных функций на зацепление никак не влияет.
Еще раз повторить? Мне не сложно: Добавляя новый метод в публичный контракт — ты увеличиваешь количество способов, которыми можно добраться до приватных данных => увеличиваешь связность. Так понятнее?

КЛ>Тут люди фактически пишут тоже самое, что и я. Они рекомендуют группировать однородные функции в отдельные модули, а не пихать в один класс методы, предназначенные для решения разных задач.
Ты не понял зачем они это предлагают делать, конечная цель — уменьшение публичного контракта, что автоматически приведет к уменьшению связности.

КЛ> Разве алгоритм сортировки не может быть указан в качестве параметра? Почему? Хочет пользователь отсортировать массив quicksort'ом — указывает один параметр, а хочет отсортировать пузырьком — указывает другой параметр. В чем Вы видите проблему?
Я уже писал в чем проблема. Подробно.

КЛ>Вы хотели написать, что тем выше "зацепление"?
Нет. Я хотел сказать ровно то, что сказал — "...тем выше связность", пользуйся общепринятой терминологией, не надо изобретать свою.

КЛ>Если Вы обратитесь к источникам, которые я приводил выше (Гради Буч, Тимати Бадд), то увидите, что зацепление характеризует зависимость между модулями, а не между интерфейсом (контрактом) и его реализацией.
Если ты обратишься к любым, вменяемым источникам, включая того же Буча или тем, что я приводил выше, и дашь себе труд прочитать их внимательно, то станет очевидно, что связность нифига не зависит от того чем ты оперируешь, модулями ли, классами, пространствами имен, сборками или еще чем... Это более фундаментальное понятие, которое характеризуется лишь числом вносимых изменений в компоненты системы при изменении реализации одной из компонент.

КЛ>Поэтому количество функций в контракте не играет никакой роли.
Именно по этому, число функций в контракте играет первостепенную роль.

КЛ>Никакого не вижу плюса.
О, начинаешь понимать?

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

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

КЛ>А аргументы? Поверьте, банальное шапкозакидательство без аргументации на профессиональном форуме для инженеров как-то не катит.
Практически весь форум профессиональных инженеров, оптом, пытается донести до тебя простую мысль, о том что ты... заблуждаешься как в посылках, так и в выводах. Устали уже, внятную аргументацию ты либо игнорируешь, либо она до тебя просто не доходит, поэтому воспринимай это как простое выражение отношения..

Здравствуйте, WolfHound, Вы писали:

WH>А все остальное как всегда проигнорировал.
WH>Я даже не удивлен.

Так там нечего комментировать. Вы просто взяли силлогизм и неправильно перевернули его — типичная логическая ошибка.

WH>И фигня в том что какой интерфейс такая и реализация.
WH>А раз реализация дерьмо то и интерфейс не лучше.

Смотрите сами:

Силлогизм-1: Если интерфейс продуман плохо, то и реализация плохая.
Силлогизм-2: Если реализация плохая, то и интерфейс плохой.

Если с истинностью силлогизма-1 можно согласиться, то с истинностью силлогизма-2 — нет. Ибо правильный обращенный силлогизм формулируется так:

Силлогизм-3: Некоторым плохим реализациям соответствует плохой интерфейс.

Но на этом основании нельзя сделать вывод, что конкретной плохой (на Ваш взгляд) реализации соответствует плохой интерфейс.

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

WH>А я тебе сразу сказал с чем столкнулся. Главная засада из которой прямо или косвенно растут все остальные это фундаментально разные принципы работы этих платформ. Любой спец знакомый в общих чертах с win и web (а тех кто совсем не знаком пожалуй нет) легко выведет кучу очевидных проблем (о них я тоже говорил). Ну еще не нужно забывать про кучу не очевидных заботливо раскиданных меокософтом, w3c и производителями браузеров.

Не я первым начал ставить собеседника в позицию интервьюируемого — так что на то, что я скажу дальше — не обижайтесь. Если Кандидат у нас на собеседовании ответит на вопрос похожим образом (как это сделали Вы), он сразу же и без объяснений пойдет далеким раутом. Ибо умение конкретизировать задачи — одно из главных требований к инженеру. Потому что абстрактные задачи (типа "все плохо" или "все в дерьме") решить невозможно.

WH>Вот только ты счел это слишкм абстрактным и стал требовать деталей.
WH>А их в этой задачи столько что...
Зачем перечислять все проблемы? Конкретизируйте 2 — 3.

Здравствуйте, IB,

Относительно терминов

Мне несложно повторить еще раз: в русскоязычной технической литературе приняты термины зацепление и связность.

Цитата-1:

"Двумя важными понятиями при разработке программ являются зацепление (coupling) и связность (cohesion). Связность — это мера того, насколько отдельная компонента образует логически законченную, осмысленную единицу. Высокая связность достигается объединением в одной компоненте соотносящихся (в том или ином смысле) друг с другом функций. <...>

С другой стороны, зацепление возникает, если одна программная компонента должна иметь доступ к данным (состоянию) другой компоненты. Следует избегать таких ситуаций".


Тимоти Бадд. Объектно-ориентированное программирование в действии / Пер. с англ. — СПб.: Питер, 1997. — с. 61 — 62.

Цитата-2:

"Термин зацепление взят из структурного проектирования, но в более вольном толковании он используется и в объектно-ориентированном проектировании. Стивенс, Майерс и Константайн определяют зацепление как "степень глубины связей между отдельными модулями. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями". <...>

Понятие связности также заимствовано из структурного проектирования. Связность — это степень взаимодействия между элементами отдельного модуля (а для OOD еще и отдельного класса или объекта), характеристика его насыщенности. <...> Наиболее желательной является функциональная связность, при которой все элементы класса или модуля тесно взаимодействую в достижении определенной цели."


Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер. с англ. — М.: "Издательство Бином", СПб: "Невский диалект", 1998 г. — с. 139.

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

Из цитаты-2 следует: зацепление характеризуется как "степень глубины связей между отдельными модулями. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями"

Здравствуйте, IB, Вы писали:

IB>Видишь ли, человечество за долгое время своего существования, выработало хороший подход к решению задач. Если получается формаизовать условие и решение, то можно выработать методику, позволяющую решать все однотипные задачки. В данном случае, проблема в том, что "монолитность", сама по себе формализации не поддается, а вот степень "бедности" контракта — очень хороший формальный критерий, который практически напрямую указывает на степень "монолитности". У того же Меерса этому посвящено довольно много.

Степень "бедности" контракта — это подсистемный критерий. Его можно использовать, но в ряде случаев (причем довольно значительном) он будет показывать неверный результат. Т.к. "бедность" может быть обусловлена совершенно разными причинами. Например, когда-то давно я был знаком с программистом, который любил экспортировать из DLL'и только одну функцию с именем DoAll() и без параметров. Контракт, как Вы понимаете бедный. И поэтому он начисто лишает вызывающую сторону какой-либо возможности по управлению выполняемой операции.

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

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

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

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

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

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Относительно терминов

Мой тебе совет — никогда не опирайся на терминологию в русских переводах IT литературы — в 99% случаев качество переводов ниже плинтуса, а переводчики те же самые, что переводят там же любовные романы. В русскоязычном community принят термин связность.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Мне несложно повторить еще раз:
Можешь не повторяться, в русскоязычной профессиональной литературе coupling = "связность" (cohension = "сродство").

КЛ>Тимоти Бадд. Объектно-ориентированное программирование в действии / Пер. с англ. — СПб.: Питер, 1997. — с. 61 — 62.
Выкини этот перевод.

КЛ>Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер. с англ. — М.: "Издательство Бином", СПб: "Невский диалект", 1998 г. — с. 139.
И этот перевод тоже выкини, вообще, привыкай оригиналы читать, меньше непоняток будет.
За "Питерские" переводы вообще стрелять надо, достаточно вспомнить как они GoF перевели.

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

Герб Саттер, Андрей Александреску. Стандарты программирования на C++. 101 правило и рекомендация. Серия C++ In-Depth, – М.: “Вильямс”, 2005. – 224 с.

КЛ>Из цитаты-2 следует: зацепление характеризуется как "степень глубины связей между отдельными модулями. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями"
Угу, осталось разобраться, что же там переводчик имел ввиду под "модулями" и что такое "степень глубины связей"? Ась?
Перевожу — "степень глубины связей" (заметь связей, а не зацеплений, что так же говорит о качестве перевода), характеризуется количеством изменений, которые надо проделать в системе, при модификации одного "модуля".
(с) Меерс.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Степень "бедности" контракта — это подсистемный критерий.
Он не подсистемный и не надсистемный — он объективный.

КЛ>Его можно использовать, но в ряде случаев (причем довольно значительном) он будет показывать неверный результат.
Угу, а в остальных 99% случаев он дает абсолютно верный результат, что вполне достаточно для практического применения.

КЛ> Т.к. "бедность" может быть обусловлена совершенно разными причинами.
Может, но мы же не о клинических случаях говорим? Это совершенно другой аспект проблемы, который в данной дискусии остался за кадром.

КЛ>Когда Вы говорите о "бедности" контракта модуля, Вы как-то забываете, что модуль создается ради того, чтобы оказывать сервис.
Никто об этом не забывает, не меняй тему разговора...

КЛ> Поэтому интерфейс модуля должен быть таким, чтобы другому модулю, обращаемуся к первому через интерфейс, было удобно.
Удобство понятние растяжимое. Сейчас разговор о том, что ни в коем случае нельзя добиваться удобства, за счет раздувания контракта.

КЛ>С чего это Вы сделали такой вывод?
Из твоих слов. Одно из двух, либо ты свои мысли внятно выражать не умеешь (что странно для человека рекламирующего свои презентации), либо неумело увиливаешь, когда к стенке приперают, как то не тянет для "профессионального форума".

КЛ> Есть один метод сортировки на входе, который, в зависимости от параметра, вызывает уже конкретную реализацию. Соответственно, метод реализации конкретного алгоритма сортировки не знает о других методах.
У нас же единый интерфейс у всех методов, значит параметр указывающий на алгоритм есть во всех реализациях, значит они должны знать друг о друге.

КЛ>Но можно поступить и по-другому: есть несколько методов сортировки, в названии которых "зашито" и название алгоритма. Пользователь вызывает любой из них.
Я уже достаточно подробно описал, почему такой подход является кривым.

КЛ>Это отмазка, попытка психологического давления и явный уход от ответа на вопрос.
Никакого ухода, я вполне четко аргументировал свою фразу..

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Так там нечего комментировать. Вы просто взяли силлогизм и неправильно перевернули его — типичная логическая ошибка.
Я там все что нужно написал.
И ничего не перевертывал.
Про переворачивания это ты придумал.

Ибо для того чтобы плохо реализовать качественно спроектированные интерфейсы нужно приложить большие усилия.

И это факт медицинский.
Ибо хорошо формализованные интерфейсы очень сильно ограничивают вольности реализации. И это хорошо. Ибо излишняя свобода выбора увеличивает поле для ошибок.
Для того чтобы сделать твое решение на моих интерфейсах придется столько с бубном попрыгать что даже самый упертый любитель табличек забъет и напишет все на классах. (Или уволится... это пожалуй лучшее что он может сделать...)
Да классы он може написать отвратно. НО того ужоса что у тебя не получится.

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

WH>>Вот только ты счел это слишкм абстрактным и стал требовать деталей.
WH>>А их в этой задачи столько что...
КЛ>Зачем перечислять все проблемы? Конкретизируйте 2 — 3.
Болие подробное описание любого из пунктов потянет на книгу или по крайней мере на статью.

1)Принципиально разные модели UI. Те вобще ничего общего кроме того что и то и другое UI.
Книга по win GUI запросто тянет на болие 1000 страниц.
С книгой по web таже фигня.

2)Несовместимость браузеров.
Нужно перевернуть инте в верх дном чтобы узнать в каком браузе ре и как работет.

3)Различные принципы кеширования.
Если в случае с win клиентом даже если он тонкий можно кешировать на клиенте что-попало то в случае с web такие фокусы не пройдут.

4)Различные методы обеспечения безопасности.
В случае с win клиентом можно прекрутить любой протокол.
В случае с web колличество решений резко сокращается.

5)Различные методы обеспечения быстродействия.
В случае с win события от пользователя доходят мнгновенно.
В случае с web обращение к серверу может достигать секунд. Для UI это неприемлемые задержки.
Те нам нужно кучу всего навернуть на жаба скрипт.

6)Различные методы валидации пользовательского ввода.
Если в случае с толстым win клиентом мы можем все валидировать на клиенте. То в случае с тонким и темболие web (ибо жабаскрипты могут быть отключены) мы должны повторить все проверки на сервере.

7)Различные методы поддержки сессий.
Проблема с web в том что пользователь может сохранить урлик...
Да и кластеризация сервера добавляет своих тараканов...

...
Да там вобще практически ничего общего нет.

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

Те модель системы должна быть такой чтобы можно было все это сгенерить.
Единственный способ это сделать создать модель не завязаную ни на web ни на win.

Задача очень большого объема и требует серьезных объемов работ и исследований.
И чтобы на таких задачах вобще чегото добиться нужно уметь отсекать целые классы решений.
Один из приемов отсекания различного мусора это какраз формализация контрактов.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Кирилл Лебедев, Вы писали:


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

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

public interface ISorter[T]
{
    Sort(collection : IList[T], comparer : IComparer[T]) : void
}

public class MergeSort[T] : ISorter[T]
{}

public class BubbleSort[T] : ISorter[T]
{}

public interface IMySortableCollection[T] : IList[T]
{
    Sort(sorter : ISorter[T]) : void;
}

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Кроме того, обратите внимание, что Вы так по-человечески и не описали Вашу задачу — так, чтобы программист, не программирующий на .NET, мог ее понять. От конкретизации Вы уклоняетесь, ссылаясь на абстрагирование. От описания конкретных проблем скрещивания Win с Web тоже уклоняетесь, ссылаясь на месяцы работы.

Кирилл, вы с WolfHound-ом говорите об ортогональных задачах. WolfHound — о построении компонентной инфраструктуры. Ты — о редакторе самом по себе. Справедливости ради, замечу, что WolfHound вполне понятно объяснил, что к чему, просто он опустил некоторые моменты, очевидные для тех, кто плотно занимался подобными задачами. Его интерфейсы решают задачу, которую можно примерно сформулировать так: предоставить описание свойств объектов (или что там — компоненты, модули...) в рамках определённых соглашений. Ну, наприимер, нужно явно "сказать": является свойство "сбрасываемым" или нет.

Вся же прикладная конкретика (конкретные системы координат, конкретные наборы свойств и прочее) обслуживается самими компонентами. В известном смысле, работа с такими компонентами похожа на использование void*, вернее — на CBaseObject* с последующим приведением к производному типу. Например, перед использованием такого компонента нужно пройтись по его свойствам, проверить наличие тех или иных свойств и их типов, а в случае .Net, вполне вероятно — сгенерировать соответствующие обёртки через Reflection/Emit. По-моему, WolfHound об этом тоже упоминал.

WH>>Главное это то что в контрактах контролов остается только то что там должно быть и ничего больше.
КЛ>Контракты — это уже результат проектирования. Контракты нужны для решения задачи. В условиях, когда задача не определена и не поставлена, бесполезно обсуждать правильность или неправимльность, полезность или бесполезность того или иного контракта.

Верно. Но в данном случае, говоря о контрактах нужно разделить их на две группы. Первая — контракты самой системы описания типов. Это часть компонентной инфраструктуры и сюда входит всё, что касается описания типа. Вторая группа — собственно прикладные контракты компонентов, в которую входят разнообразные системы координат, заголовки, тексты и прочее. Фокус в том, что прикладные контракты обрабатываются опосредованно через инфраструктурную составляющую.

---

2 WolfHound сотоварищи: Вообще, ребята, за вами прикольно наблюдать. Как только почуяли, что оппонент играет не на вашем поле, так разве что дураком не обозвали.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>2 WolfHound сотоварищи: Вообще, ребята, за вами прикольно наблюдать. Как только почуяли, что оппонент играет не на вашем поле, так разве что дураком не обозвали.
Ты на его "решение" посмотри.
И лично я очень сильно сомневаюсь что на других задачах будет другой результат.

Здравствуйте, WolfHound, Вы писали:

ГВ>>2 WolfHound сотоварищи: Вообще, ребята, за вами прикольно наблюдать. Как только почуяли, что оппонент играет не на вашем поле, так разве что дураком не обозвали.
WH>Ты на его "решение" посмотри.

Обыкновенная затычка для закрывания дыры в дискуссии

Автор: Кирилл Лебедев
Дата: 25.05.07

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

WH>И лично я очень сильно сомневаюсь что на других задачах будет другой результат.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А меня, вот, обилие "может быть" в упомянутом постинге заставляет сомневаться в "конечности" этого результата.
Просто сам факт использования таких структур говорит о многом.

ID.
Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
Text.
Picture.

А затычка там или нет это вопрос десятый.
Человек либо всегда проектирует как следует либо всегда проектирует отвратно.

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

Здравствуйте, WolfHound, Вы писали:

WH>Основное требование а компоненте это связывание во время работы программы.
WH>Есдинственный способ связать что-то с чем-то в сатически типизированном языке это интерфейсы.

Разве эти интерфейсы относятся к компонентам?

WH>    public interface IElementBase
WH>    public interface IEventBase : IElementBase
WH>    public interface IPropertyBase : IElementBase

WH>    public interface IAttachedElement : IElementBase
WH>    public interface IElement : IElementBase

WH>    public interface IProperty : IPropertyBase, IElement
WH>    public interface IEvent : IEventBase, IElement
WH>    public interface IAttachedProperty : IPropertyBase, IAttachedElement
WH>    public interface IAttachedEvent : IEventBase, IAttachedElement

WH>    public interface IType

Мы ведь говорим о них, если Вы еще не забыли .

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

А суть проблемы в том, что Вы наплодили 10 интерфейсов и еще 5 классов для их реализации. И к тому же не можете внятно объяснить, какой интерфейс за что у Вас отвечает. Говорите много "умных" слов про модели данных и метаданных. Но простая мысль о том, что не надо создавать класс (или интерфейс), у которого нет обязанностей, Вам почему-то в голову не приходит. А ведь именно об этом сказано в моей презентации.

Тут Вам все-таки надо определиться:

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

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

WH>Хотя если учесть то что экраны с большим колличеством точек на дюйм при сохранении растра не реализуймы... просто столько данных не прокачать... ну сам посчитай поток 6000*8000*3(а то и 6 байт на пиксель)*100(кадров в секунду)

Ну вот при чем тут 6000 на 8000? Какое отношение это имеет к лэйаутам? Зачем вообще нужно хранить всю сетку? Почему нельзя указывать только целочисленные координаты контролов? Извините, но Ваше сообщение выглядит, как неаргументированный поток сознания. Вы уж либо по-человечески все объясните, либо прекратите "выкрикивать шаманские заклинания и стучать в бубен".

Я уже писал, что неумение поставить и объяснить задачу фактически означает приговор для инженера. Пожалуй, соглашусь с мнением Геннадия Васильева и сочту, что Вы уклоняетесь от объяснений лишь для того, чтобы использовать мое незнание некоторых деталей (в силу того, что я не программирую на .NET) в качестве преимущества в споре. Похоже, Вы чувствуете, что объясни Вы все мне по-человечески, Ваш дизайн будет разбит в пух и прах, а предложенное решение — будет выглядеть проще и гораздо элегантнее.

Здравствуйте, Кирилл Лебедев, Вы писали:

WH>>Основное требование а компоненте это связывание во время работы программы.
WH>>Есдинственный способ связать что-то с чем-то в сатически типизированном языке это интерфейсы.

КЛ>Разве эти интерфейсы относятся к компонентам?

Ключевое слово: "описание структуры данных". Глянь сюда

Автор: Геннадий Васильев
Дата: 21.06.07

.