Дилара Валитова
Элементарные паттерны описаны вот в этой книге Смит Дж. "Элементарные шаблоны проектирования". Принцип такой - сначала изучаем элементарные паттерны (кирпичи), потом более сложные Банды четырех (стены).
Аналитики изучают основы ООАП и паттерны:
- для того чтобы понимать текущую реализацию и не сломать то, что работает;
- для того, чтобы не тратить время на проекте для нахождения общего языка с разработчиком;
- предварительная проработка архитектуры решения, чтобы сразу увидеть слабые места решения, а также учесть, например, масштабирование.
При этом нет задачи декомпозировать объекты, так как это происходит на уровне кода. Достаточно видеть укрупненно из каких классов будет состоять система и как они между собой связаны.
Очень часто встречается просто журнал, просто документ, просто набор данных, например, об оборудовании. При этом они не участвуют в процессах согласования или передачи от одной роли к другой.
Для случая с журналом абстракция также присутствует, например, нам не нужно физическое место его хранения. При этом в класс могут добавиться свойства, которых нет в журнале, но заказчик хочет их фиксировать.
Сомневаюсь, что Гради Буч определял ООП только для сложных объектов, не встречала такого утверждения в его книгах.
Тогда остается обратиться к первоисточнику - из книги Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений
1. Аналог при этом не является оригиналом, а значит это не одно и тоже.
2. То что не в системе, является объектом изучения, аналитики уточняют у заказчика:
- необходимо ли вносить данный объект в систему;
- какие атрибуты должны быть в системе;
- какие действия необходимо будет совершать над объектом в системе.
Далее аналитик проектирует и описывает классы системы на основе собранной информации об автоматизируемых объектах.
Разработчик в соответствии с описанием реализует систему.
И в системе начинается создание экземпляров класса.
При этом экземпляр класса не равно объект, который мы первоначально исследовали, так как в любом случае присутствует абстракция от некоторых свойств изучаемого объекта и действий, которые можно с ним совершить.
Вы уже говорите о реализации. Когда аналитик только собирает информацию для проектирования, он исследует все, что должно попасть в систему и только потом появляются классы. Поэтому и остается вопрос - чем является бумажный журнал при проектировании системы?
2. По этому пункту соглашусь, что интерфейс - это не класс, но в языке UML, который используется для проектирования, интерфейс отображается как класс. Что и указано в книге авторов Буч, Рамбо, Якобсон: Язык UML. Руководство пользователя.
3. Предлагаю взять другой пример. Стоит задача автоматизировать бумажный документооборот, например, журнал, в котором фиксируется поступившая входящая корреспонденция. Чем в этом случае является бумажный журнал при проектировании системы?
Давайте тогда вместе распутываться:
1. Если мы рассматриваем документооборот компании, то в нем существуют объекты и входящих писем и исходящих. Также при автоматизации в рамках одной системы электронного документооборота создает как класс для Входящих писем, так и класс для Исходящих писем. Поэтому в этой статье не рассматриваются другие системы.
2. В ООП методы не являются самостоятельными элементами, как класс. А вот интерфейсы вполне могут обладать атрибутами.
3. С понятием Объект в ООП есть путаница, потому что его применяют в разных контекстах. Когда мы исследуем на проекте, мы исследуем объекты, это могут быть как физические объекты, так и абстрактные. А вот то, что является порождением класса является его экземпляром, но нередко экземпляр класса также называют объектом.
Если брать аналогию с домами, то архитектор прежде, чем сделать свой первый чертеж долго изучает различные объекты архитектуры, построенные в разных стилях. Далее он с заказчиком определяет в каком стиле он хочет построить дом и создает чертежи (классы). На основе чертежей рабочие строят дом (создается экземпляр класса). В последствии этот дом может также стать объектом изучения.
Спасибо за комментарий, учту этот момент при написании второй статьи
ООП как и любой инструмент имеет свои достоинства и недостатки, а также область применения. Если используется язык ООП или у вас уже есть продукт написанный на языке ООП, то вы или адаптируетесь под его использование или полностью переписываете весь продукт на другом языке. Из двух зол обычно выбирают меньшее.
Первая статья из цикла статей о паттернах дана для погружения в объектно-ориентированную парадигму, чтобы далее были понятны употребляемые термины.
Аналитики при проектировании продукта или модификаций используют язык понятный тем, для кого они описывают эти изменения. Аналитик и с заказчиком общается на одном языке, например, используя специфичную отраслевую терминологию, и с разработчиком.
Аналитики не смотрят в код, смотрят в документацию описывающее решение. При этом документация содержит диаграммы классов, описание свойств и методов классов.
В свою очередь при изменении решения, аналитики должны оставить информацию о том какие классы изменялись, в чем состоят эти изменения, какие классы добавились с описанием свойств и методов.
Возможно где-то это делают разработчики, в нашем случае разработчики только пишут код.