Выбор классов в в объектно-ориентированном и процедурном программировании

Опубликовал read-php в 28.01.2011 Категория: Объекты и методология проектирования в ООП на PHP

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

При моделировании реальной ситуации это может показаться простым. Обычно объектно-ориентированные системы — это программное представление реальных вещей, поскольку часто используются классы Person, Invoice и Shop. Отсюда можно предположить, что определение классов — это вопрос нахождения некоторых объектов в системе и придания им функциональности с помощью методов. Это неплохая отправная точка, но тут таятся некоторые опасности. Если рассматривать класс как существительное, как подлежащее для любого количества глаголов, то окажется, что он будет все больше расширяться, потому что в ходе разработки и внесения изменений потребуется, чтобы класс выполнял все больше и больше операций.

Давайте рассмотрим пример с классом ShopProduct. который мы создали раньше. Наша система предназначена для того, чтобы продавать товары покупателям, поэтому определение класса ShopProduct — это очевидное решение. Но будет ли это решение единственным? Для доступа к данным о товаре мы предоставляем методы getTitle ( ) и getPrice ( ). Если нас попросят обеспечить механизм для вывода краткой информации о товаре для счетов-фактур и уведомлений о доставке товаров, то, наверное, имеет смысл определить метод write ( ). Когда клиент попросит нас обеспечить механизм выдачи краткой информации в различных форматах, мы снова обратимся к нашему классу и надлежащим образом создадим методы writeXML ( ) и writeXHTML ( ) в дополнение к методу write ( ). Либо добавим в код метода write () условные операторы, чтобы выводить данные в различных форматах в соответствии со значением входного аргумента.

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

Так что мы должны думать по поводу определения классов? Наилучший подход — представлять, что класс имеет основную обязанность, и сделать эту обязанность как можно более единичной и специализированной. Выразите эту обязанность словами. Считается, что обязанность класса должна описываться не более чем 25 словами, с редкими включениями союзов «и» или «или». И если предложение становится слишком длинным или «тонет» в дополнительных формулировках, значит, пришло время подумать об определении новых классов с новыми обязанностями.

Например, обязанность класса ShopProduct — хранить информацию о товаре. И если мы добавляем методы для вывода данных в различных форматах, то тем самым вводим новую сферу ответственности (т.е. обязанностей): отображение информации о продукте. На самом деле на основе этих отдельных обязанностей мы определили не один, а два класса. Класс ShopProduct остался отвечать за хранение информации о товарах, a shopProductWriter берет на себя ответственность за отображение этой информации. А уточнение этих обязанностей осуществляется с помощью отдельных подклассов.

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

Комментариев нет

Добавить комментарий