понедельник, ноября 19, 2007

Проблемы построения объектных моделей.

Самое сложное в проектировании программных систем - это проектирование :)
Вот буквально вчера нарыл интересную статью на эту тему, на абсолютно не профильном сайте: "ОСВОБОЖДЕНИЕ УЗНИКОВ ОПЕРАТОРА "IF"
Прочитал с интересом. Досталось там и Гради Бучу за его примеры из книжки "Объектно-ориентированный анализ и проектирование с примерами приложений на C++". И вобщем-то поделом досталось. В защиту классика скажу лишь, что примеры в книжке призваны иллюстрировать те или иные понятия и принципы, а с прикладной точки зрения они вполне могут быть не очень удачными. Так и не в этом их цель.
Весьма смачно проилюстрированы проблемы, которые возникают при построении развесистых иерархий классов.
Правда, под конец статьи авторы свалились в частности, и выводы у них получились тоже достаточно частные. На самом деле, для решения описанных в статье проблем существуют хорошо известные методики, такие как проектирование на онове распределения обязанностей и GRASP шаблоны, модели входов выходов, модели потоков данных и т.д.

3 комментария:

Анонимный комментирует...

Да. Если придерживаться принципа открытия-закрытия то можно избежать всех проблем, которые описаны в статье.
НО!
Легко говорить о решении проблемы, которая у тебе перед носом стоит.
А вот решить проблему, которая может появиться (а может и не появиться).
Вот например как узнать, где остановиться создавая расширяемые классы?
Ведь в примере со столом заказчик мог пытаться создать стол вообще без ножек (антигравитационный стол) и т.д. и т.п.
Риск получить систему не имеющую возможности к расширению с определенной стороны есть, и его ни как не избежать :(

Анонимный комментирует...

Легко говорить о решении проблемы, которая у тебе перед носом стоит.
А вот решить проблему, которая может появиться (а может и не появиться).


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

Анонимный комментирует...

Давно думаю над возможностью применения ТРИЗ в software engineering... IBA в Минске предлагает курс "ре-инжиниринг бизнес-процессов методами триз", мож что интересное...
Указанная статья что-то такое и применяет.