Методика проектирования, итеративность + ОО. (полуночная лекция) (комментарии)

Методика проектирования, итеративность + ОО. (полуночная лекция) (комментарии)

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

Немножко ремарок по поводу ровно одной фразы.

> <xmvlad> вообще весь смысл ОО, это скрытие (инкапсуляция) сильной связности,
> и построение системы на основе слабой связности(внешней), по крайней мере к этому надо стремится :)

В этой (в целом верной) фразе перепутаны причина и следствие.

И еще немножко не устоялась терминология :)
Термины:
Связность (cohesion) - это хорошо, сильносвязные (highly cohesive) системы - это очень хорошо.
В русском языке под cohesion проще всего понимать однозначно положительное "сплочённость" ("сплочённая команда").
Сцеплённость (coupling) - это плохо, сильносцеплённые (tightly coupled) системы - это очень плохо.
В русском языке - однозначно отрицательное "спутанность" ("клубок", "макаронная фабрика").

Построение слабосцеплённых (decoupled) сильносвязных (cohesive) систем - это (никак не связанный с ОО) принцип организационной архитектуры, связанный с необходимостью минимизации зависимостей (т.е. рисков) и максимизации компетентности (т.е. ответственности).

Естественно, связность и сцеплённость неотделимы друг от друга.
Абсолютно расцеплённая система не является системой.
Как правило, в абсолютно расцеплённой "системе" до абсурда доведена связность компонентов: они самодостаточны.
И наоборот: абсолютно монолитные (сцеплённые) компоненты ("вещи в себе") по необходимости разрушают систему.
"Специалист подобен флюсу" и т.п.

ОО и data-driven дизайн в средах с ограниченными выразительными средствами (C++, например) очень интересно взаимодействуют в плане связности: data-driven создает вне языка (вне кода) высокосистемные артефакты с высокой степенью связности и низкой зацеплённостью ценой разрушения ОО и связности в коде.

Классические примеры: GoF, интепретаторы внеязыковых ОО моделей, "отделение" данных с собственной ОО-моделью от кода с интепретатором этой модели и т.п.

Если кому интересно, можно об этом поговорить.

aruslan
Очень интересно.

Основной вопрос: как и почему data-driven разрушает ОО дизайн?

И еще не понял примера с GoF.

p.s.
>высокосистемные артефакты с высокой степенью связности и низкой зацеплённостью
три раза перечитывал фразу :)

aruslan
Спасибо за разъяснения, но последние три абзаца не совсем понял, хотелось бы об этом подробнее послушать

aruslan

>Связность (cohesion) - это хорошо, сильносвязные (highly cohesive) системы - это очень хорошо.
>В русском языке под cohesion проще всего понимать однозначно положительное "сплочённость" ("сплочённая команда").
>Сцеплённость (coupling) - это плохо, сильносцеплённые (tightly coupled) системы - это очень плохо.
>В русском языке - однозначно отрицательное "спутанность" ("клубок", "макаронная фабрика").
кхм... тога вопрос чем эти характеристики принципиально отличаются друг от друга, и как их можно "измерить"?

>ОО и data-driven дизайн в средах с ограниченными выразительными средствами (C++, например) очень интересно
> взаимодействуют в плане связности: data-driven создает вне языка (вне кода) высокосистемные артефакты с высокой
> степенью связности и низкой зацеплённостью ценой разрушения ОО и связности в коде.
было бы интересно, ты не мог бы показать несколько более конкретных примеров? :)
да и про GoF тоже не понятно, каким образом паттерны разрушают ОО %)

Если есть немного времени, было бы очень интересно услышать(думаю и не мне одному), что то в духе - real world issues, from prof to noob :) примерно в следующем "формате" (можно и без, все равно):
1.  три наиболее значительные совершненные вами ошибки .
2.  три основные проблемы, с которыми скорее всего, столкнется "начинающий" разработчик (на ваш взгляд)
3.  три совета "начинающему" разработчику
тематика в принципе любая, процесс разработки/архитектура движка/архитектура рендера.

>> ОО и data-driven дизайн в средах с ограниченными выразительными средствами (C++, например)
>> очень интересно взаимодействуют в плане связности: data-driven создает вне языка (вне кода)
>> высокосистемные артефакты с высокой степенью связности и низкой зацеплённостью ценой
>> разрушения ОО и связности в коде.

> Основной вопрос: как и почему data-driven разрушает ОО дизайн?

ОО дизайн предполагает существование сущностей, отражающих прикладную область.
Например, если (гипотетически) в прикладной области есть самолёт, то её будет отражать сущность "самолёт".
(Я очень грубо утрирую, но смысл должен быть ясен.)
Как и всякий дизайн, ОО вынуждено работать в терминах языковой модели.
Конечно же, в широком смысле "языковая" модель может на самом деле предоставляться платформой, системой разработки, создаваться на лету, быть диаграммой и т.п.
В реальной жизни мы останавливаемся на уровне, где программист создаёт код.
Иными словами - на уровне языков программирования/скриптах и т.п.
Если язык ригиден (как, например, ригиден C++), то читаем дальше.

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

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

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

А ОО-модель в ригидной части превращается в "мета"модель и её интерпретатор.
Нет самолёта - есть игровые объекты, рендерные объекты, экземпляр АИ, несколько узлов в деревьях и т.п.
А где-то в данных появляются точки сборки.

Это - момент фактуализации DSL и сверх- (над-) языков.
В этот момент в "ОО-модели" ригидной части уже мало что осталось от прикладной (настоящей) ОО-модели.

Очень часто в этот же самый момент часть ОО-модели вообще выходит за рамки "DSL", "программирование", "дизайн" и отражает себя в штатном расписании.
На этом заканчивается стартовый этап работы архитектора.

Если интересно - задавайте вопросы.

xmvlad
>> В русском языке под cohesion проще всего понимать однозначно положительное "сплочённость" ("сплочённая команда").
>> В русском языке [под coupling]- однозначно отрицательное "спутанность" ("клубок", "макаронная фабрика").
> кхм... тога вопрос чем эти характеристики принципиально отличаются друг от друга, и как их можно "измерить"?

Cohesion (wikipedia)
Coupling (wikipedia)
Собственно, все простые базовые вещи можно найти по ссылкам с первого поста GvozdodeRа.

aruslan
Глубочайший респект за разруливание всего столь понятным языком. Спасибо!

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

>> data-driven создает вне языка (вне кода) высокосистемные артефакты с высокой степенью связности
>> и низкой зацеплённостью ценой разрушения ОО и связности в коде.
>> Классические примеры: GoF

> да и про GoF тоже не понятно, каким образом паттерны разрушают ОО %)

Большинство дизайн-паттернов GoF решает языковые проблемы.
Зачастую они представляют просто тот или иной способ инкапсуляции будущих изменений в тех или иных классических агрегатных структурах (по-русски - "соломенные подстилки").

Фундаментальный императив подобного рода паттернов - превращение ОО-модели в симулякр и актуализация мета-ОО-модели, одной из инстанциаций которой и является оригинальная ОО-модель (до рефакторинга).

> было бы интересно, ты не мог бы показать несколько более конкретных примеров? :)
Пример создания и разрушения ОО...
Попробую :)

Попробуем сделать окошко для моего простого приложения.  Без ОС.
С нуля.  Как игру.  Как велосипед.

Моё главное окошко состоит из рамочки, текста и одной кнопочки.

Тупой прямолинейный ОО дизайн сделает мне класс окошка, агрегирующий рамочку, текст и кнопочку.
Внимание: дизайн - верный (хотя и тупой) - мы программируем то, что нужно и ничего лишнего.
main_window  text      set_text("blabla").
main_window  frame  set_thickness(25).
main_window  button  set_text("Ok")

Но... кнопочка некрасивая получилась.  Опять set_text.  Да и реализация - сплошной copy-paste будет.
Немножко подумав, ОО дизайн попытается отразить кнопочку как немножко почти то же самое окошко.
Только без встроенной кнопочки.

Немножко ОО рефакторинга и - вуаля! - применяется паттерн Composite.

Появляется классическое "контрольный элемент".
Одной из разновидностей которого является "окошко" - набор "контрольных элементов".
Плюс "контрольный элемент" "кнопочка" (в глубине - тоже "окошко").
Плюс "текст" (не будем двигаться дальше :) ).

> -- прошло три года, успешный рост продаж, уже восьмая версия...

И вот теперь смотрим на код.
Где моё любимое (и - единственное на прикладном уровне!) окошко?!
Где моя кнопулечка?!

Почему я должен писать вот такой вот код:
main_window 
  find_control  "ok_button" 
    cast_to_button 
        find_control  "button_text" 
          cast_to_text
              set_text "Ok"

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

И вообще - почему, блин, у меня описание моего простого окошка уехало куда-то в набор XML?
Что это за парень возле меня, которому я выплачиваю деньги, а он пишет какие-то координаты в XML?
Ой, а это кто?  Художник?
Какой GIF?
Какой JPEG?

Кто все эти люди?!
В отделе кадров сказали, что специалист по XAML просит неприличных денег?!

ААААААА!!!!

> -- отрезать здесь

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

Уф, устал.
Надеюсь, я внятно выразился: GoF - это хорошо и правильно и даже в чём-то ОО.
Просто это - мета-ОО - и дальше по списку.

>Cohesion (wikipedia)
>Coupling (wikipedia)
>Собственно, все простые базовые вещи можно найти по ссылкам с первого поста GvozdodeRа.
читал я это, все равно какие-то мутноватые понятия, почему бы просто не заменить это понятием _связности_ в самом общем смысле(обращение к переменной, объекту, етк), если связность можно минимизировать, значит то что было до минимизации - cohension, если нельзя то - coupling

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

Штатное расписание в моей компании.

xmvlad
>>Собственно, все простые базовые вещи можно найти по ссылкам с первого поста GvozdodeRа.
> читал я это, все равно какие-то мутноватые понятия, почему бы просто не заменить это понятие
> _связности_ в самом общем смысле (обращение к переменной, объекту, етк), если связность можно
> минимизировать, значит то что было до минимизации - cohension, если нельзя то - coupling

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

Пример.

Вот ты - это cohesion.  Твои запчасти присущи тебе как человеку homo sapiens и в чём-то примату.
Ты им в этом не признаёшься, но ты их любишь.

На тебе есть одежда.
Если одежда на тебе растёт - это coupling.  Потому что неудобно.
Тебе нужна иногда одна, иногда другая. 
Иногда - без ;)

А если одежду можно снять и повесить на вешалку - это не coupling.
Это - система.
Потому что не ты+одежда, а ты умеешь одеваться.
Твой скилл - это умение, он cohesive с тобой.
А одежда - это другая сущность.
Всё вместе - система.

Твоя трактовка тоже имеет право на существование:
Внешняя точка зрения: есть просто запчасти. 
Если сами отвалились - это одежда.
Если пришлось поработать скальпелем - это органы.

Только вот вряд ли тебе по душе придётся это паталогоанатомическое упражнение ;)

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

aruslan
ну так мы и находимся из вне системы, представляя из себя скорее хирурга, чем представителя этой системы, и с точки зрения хирурга, иследующего неизвестный объект, процессуальная точка зрения, вполне логична :))) если отваливается - одежда, если нет - орган :))
это к тому, что каких-то более менее "объективных" измеряемых "определений" cohesion/coupling я не видел %)

xmvlad
ммм... предполагалось, что мы дизайним тебя с одеждой.
то есть есть задача - чтобы было тепло/красиво/удобно/метросексуально.
и еще есть ты.

два решения.
растить её на теле и надевать.
оба - правомерны.  но в разных случаях.

и вот тут случается то, почему архитектура - это не паттерны GoF ;)

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

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