Лекция #3: Методы проектирования, ключевые принципы ОО. [Лектор - xmvlad]
Автор: Vladislav Gusev
<xmvlad> значит так, ТЗ - техническое задание, в идеале - описание функциональности того что должно быть в результате.
<xmvlad> основная характеристика ТЗ: темпоральная неустойчивость :) ТЗ может изменятся, когда угодно, как угодно, и под воздействием множества факторов, начиная от заказчика и кончая - изменения
<xmvlad> видения системы со стороны разработчика.
<xmvlad> задача разработчика, имея ТЗ создать работающую систему :)
<xmvlad> архитектура(етк) - модели создаваемые разработчиком и помогающие ему а) понимать систему, (следствие а) б) а значит и разрабатывать ее, в) бороться с различными внешними "негативными воздействиями", вроде неустойчивости ТЗ, недостатка понимания системы на начальных этапах етк...
<xmvlad> поэтому бессмысленно рассматривать архитектуру как некоторую статическую сущность, существующую отдельно от процесса разработки
<xmvlad> введение закончено
<xmvlad> метод проектирования сверху-вниз
<xmvlad> архитектура сверху-вниз - разбиение основной задачи(то что описано в ТЗ) на подзадачи, решение всех подзадач дает решение основной задачи.
<xmvlad> минусы - архитектура сверху-вниз является "отражением" ТЗ, соответственно изменение ТЗ, влечет значительно изменение в архитектуре.
<xmvlad> основной минус, метода проектирования сверху-вниз - статичность, в нем практически отсутствует "процесс", то есть процесс есть, но он может быть лишь направлен на детализацию подзадач.
<xmvlad> методика проектирования снизу-вверх
<xmvlad> то же самое что и методика сверху-вниз, только сначала создаются подзадачи, а через их решение приходим к решению основной задачи, те же самые минусы, основной - строгая направленность процесса разработки снизу-вверх, такая же неустойчивость к изменениям.
<xmvlad> методика проектирования из угла на искосок, или итеравный процесс разработки + объектно ориентированная архитектура
<xmvlad> основной сущностью ООМ(объектно-ориентированной методики) является объект
<xmvlad> что такое объект?
<xmvlad> объект это целостная концептуальная сущность, обладающая некоторой функциональностью/ответсвенностью (функцями которые объект может выполнять)
<xmvlad> в некоторых книжках часто пишут, что дескать объект это отражение реальности, не верьте им, объект это некоторая концепция/абстракция/что-угодно, которая нужна здесь и сейчас для выполнения некоторых функций, не более того. далеко ходить за примерами "не реальных" объектов, думаю не надо :)
<xmvlad> тогда ОО архитектура - это связанная совокупность объектов, проще говоря система состоящая из объектов
<xmvlad> основными характеристикам ОО архитектуры являются: а) устойчивость б) сложность в) гибкость
<xmvlad> устойчивость определяет насколько "внешние воздействия" сильно воздействуют на системы, то есть приводят к значительным изменениям в ней. Чем более, система устойчива, тем меньше на нее воздействуют, "внешние факторы"
<xmvlad> сложность, определяет насколько сложно понять/понимать систему
<xmvlad> гибкость, определяет насколько легко система поддается изменению
<xmvlad> Как было сказано выше, объекты образуют систему, а если есть система должны быть и связи. Связность определяет насколько "плотно" взаимодействуют между собой объекты системы. Очевидно, чем выше связность, тем ниже устойчивость (воздействие не только на объект но и на связанные), выше сложность и ниже гибкость
<xmvlad> в общем, связность это плохо, и с ней необходимо бороться :))
<xmvlad> но некоторое количество связей все равно не обходимо, иначе просто ничто в системе не сможет взаимодействовать :)
<xmvlad> следующий пункт, сложность, рост сложности легко может привести к тому, что разработчик перестанет понимать создаваемую им систему. Если разработчик не понимает создаваемую систему, ее не понимает никто, а значит системой невозможно управлять :)))
<xmvlad> соответсвенно один из ключевых вопросов - как управлять сложностью, и не дать ей управлять тобой :)) основной правило: мочить, везде, в том числе и в сортире. как мочить: KISS(keep it simple)/лезвием Окама.
<xmvlad> кроме этого архитектура должна быть ориентирована на пользователя(программиста) и желательно представлять из себя "унифицированный"(на сколько это возможно) набор концепций легко понятных программисту. (отражать предметную область)
<xmvlad> гибкость, золотое правило: чем меньше связность, тем выше гибкость.
<xmvlad> что касается ОО архитектуры в общем то все, теперь поговорим о процессе
<xmvlad> итеративность - залог успеха
<xmvlad> никакая сложная _рабочая_ система/архитектура не может возникнуть из неоткуда, все они результат эволюции - процесс перехода от более простых _работающих_ систем, к системам более сложным.
<xmvlad> почему архитектура созданная полностью с нуля на бумаге, никогда не будет работать или по крайней мере изменится до неузнаваемости в процессе разработки?
<xmvlad> очевидно, потому что разработка это процесс, большинства "неизвестных"(необходимых для принятия архитектурнхых решений) в начале просто нет.
<xmvlad> Итеративность позволяет - переходить от более простых работающих форм к формам более сложным, и так же _работающим_
<xmvlad> тогда процесс разработки является совокупностью итераций: проектирование-> кодирование (рефакторинг) -> анализ -> следующая итерация
<xmvlad> итеративность позволяет быть уверенным, что разработка пройдет полный цикл, а значит ошибки внесенные как при проектировании, так и кодировании в большинстве будут выявлены до начала новой итерации
"движение" снизу-вверх и сверху-вниз :)
<Zeux> еще:
<Zeux> как совмещать? разбивать на подсистемы и каждую дизайнить по-своему?
<xmvlad> ээ.. ну как бы ОО это и есть совмещение :) тебя никто не заставляет идти в каком-то одном направлении.
<Zeux> ну это ясно
<Zeux> ладно, это пофиг, мне это ясно.
<xmvlad> вопрос наверное в другом зачем нужно движение сверху-вниз и снизу-вверх
<Zeux> Ты лучше про связность скажи.
<Zeux> ну, понятно, иногда ясно, что надо, но неясно как
<Zeux> иногда ясно, как, но неясно, во что это должно вылится
<xmvlad> да
<xmvlad> Связность может быть внутренней, а может быть внешней. Внутренняя связность уменьшает гибкость, и увеличивает сложность, один связанный объект сложнее понять, чем несколько простых. Изменяется весь объект, лучше иметь несколько независемыз объектов, изменение которых не будут иметь такого сильного влияния на систему
<xmvlad> соответственно первый метод борьбы со связанностью - декомпозиция объекта, то есть разбиение на более простые объекты.
<Zeux> так мы заменяем внутренние связи на внешние?
<xmvlad> да, самое главное, что бы не было слишком много внешних связей, иначе разбиение бессмысленно
<xmvlad> лучше иметь внутренние связи, чем столько же связей но внешних
<Zeux> что понимать под внутренними связями? (только не говори "связи внутри объекта" :))
<xmvlad> то есть смысл, в том что бы разделить объект, так что бы получившиеся объекты имели минимум внешних связей
<Zeux> т.е. опять же желательно пример
<xmvlad> внутренние связи это приватная часть объекта, то что не видно "из вне"
<Zeux> связи - это приватная часть объекта? Приведи пример, плиз.
<xmvlad> ну доступ к какой-то переменной, объекту, это тоже связь
<Zeux> грм. Тогда все объекты очень сильно внутрисвязаны
<Zeux> т.е. у каждого объекта до фига внутренних связей
<xmvlad> да
<xmvlad> я хочу сказать следующее
<xmvlad> если есть возможность надо выделять слабо связанные подобъекты(если они есть) и делать их связи внешними
<xmvlad> вобще весь смысл ОО, это скрытие (инкапсуляция) сильных связей, и построение системы на основе слабых внешних связей, по крайней мере к этому надо стремится :)
<Zeux> чем отличаются слабые связи от сильных? количеством?
<xmvlad> прежде всего да, количеством
<xmvlad> но не только, можно сказать что сильные связи более устойчивые, то есть
<xmvlad> стой чего то не то я сказал :))) глючу
<xmvlad> количество и локализованность
<xmvlad> то есть большое количество связей между небольшим количеством элементов
<Zeux> это признак сильной связи
<xmvlad> да
<xmvlad> сильной связности :)
20 января 2006
Комментарии [2]