Насколько сумасшедшим я должен стать, превращая вещи в предметы? - PullRequest
5 голосов
/ 04 апреля 2011

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

Но теперь я начинаю смотреть на вещи как на объекты, которые не являются такими же черно-белыми, как случай из-за того, что они являются объектом. Например, у меня есть анализатор, и обычно он возвращает некоторые строки, с которыми мне приходится иметь дело. Но у него есть один специализированный случай, когда он должен возвращать массив, и что идет в этом массиве и как он отформатирован, имеет специальные правила. Это всего две строки плюс один метод кода, но этот код показался мне не совсем подходящим для класса Parser, и я хочу превратить его в свой собственный объект «ActionArray».

Но это далеко? ООП стал молотом, который заставляет меня смотреть на все как на гвоздь? Можно ли зайти слишком далеко, превращая вещи в объекты?

Ответы [ 4 ]

2 голосов
/ 04 апреля 2011

Как общее руководство, я думаю, что Улица Сезам лучше всего говорит: вам нужен новый объект, когда «одна из этих вещей не похожа на другие» .

Слушайте свой код. Если он говорит вам, что ваши объекты загрязняются несущественным состоянием и поведением (и, следовательно, нарушают «Принцип единой ответственности»), или что одна часть вашего объекта имеет скорость изменения, которая отличается от остальных, и и так далее, он говорит вам, что вы упускаете объект.

Сделайте самое простое, что могло бы сработать . Когда это больше не работает, сделайте следующее самое простое. И так далее. В общем, это означает, что система имеет тенденцию переходить от меньшего количества более крупных объектов к более мелким объектам ; но не всегда.

Существует множество полезных ресурсов для проектирования ОО. В дополнение к уже упомянутым, я настоятельно рекомендую Шаблоны лучших практик Smalltalk и Шаблоны реализации от Кента Бека. Они используют примеры Smalltalk и Java, соответственно, но я считаю, что принципы довольно хорошо переводятся на другие языки ОО.

2 голосов
/ 04 апреля 2011

Это ваш звонок, , но вы должны думать об объектах как о реальных объектах.

Взять, к примеру, машину. Вы можете описать автомобиль с различными объектами:

  • Двигатель
  • Колеса
  • Шасси

Или вы можете описать автомобиль только одним объектом:

  • Двигатель

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

1 голос
/ 04 апреля 2011

Шаблоны дизайна - ваш друг. Класс редко существует в вакууме. Он взаимодействует с другими классами, и механизмы, с помощью которых ваши классы связаны друг с другом, напрямую влияют на вашу способность модифицировать код в будущем. При плохом дизайне классов изменения, которые вы вносите в один класс, могут сойти на нет и вызвать изменения в других классах, что заставит вас менять другие классы и т. Д.

Шаблоны проектирования заставляют задуматься о том, как классы связаны друг с другом. Например, ваш класс Parser может реализовать шаблон проектирования Strategy, чтобы абстрагировать механизм синтаксического анализа. Возможно, вы решите создать свой анализатор как шаблон дизайна шаблона, а затем каждый фактический экземпляр анализатора завершит создание шаблона.

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

0 голосов
/ 04 апреля 2011

Объектно-ориентированное программирование - довольно сложный инструмент. Многие люди сегодня попадают в один и тот же конфликт, забывая о фундаментальной цели ООП, которая заключается в улучшении поддержки кода.

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

Поток, Томас; Младен Воук, Энди Риндос (1999). «Анализ производительности объектно-ориентированного программного обеспечения, разработанного в коммерческой среде»

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...