2008-10-19 5 views
8

Где вы рисуете линию, чтобы прекратить делать абстракции и начать писать здравый код? Есть тонны примеров «кода предприятия», такие как программа дюжину-файл «FizzBuzz» ... даже кое-что простое, такие как игры RTS может иметь что-то вроде:OOP: Где остановиться Abstracting

class Player {} ;/// contains Weapons 
class Weapons{} ;/// contains BulletTypes 
class BulletType{} ;///contains descriptions of Bullets 
class Bullet{} ;///extends PlaceableObject and RenderableObject which can be placed/drawn respectively 
class PlaceableObject{} ;///has x,y,z, coords 
class RenderableObject{} ;///an object with a draw() command 
class MovingObject{}; ///an object with a move() function 

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

Любой здравомыслящий совет по этой теме?

ответ

19
  1. YAGNI (Вам не нужно это). Не создавайте абстракции, которые вы не видите немедленно или по разумной причине. Таким образом, у вас есть простая вещь, которая может стать более сложной, вместо сложных вещей, которые вы хотели бы сделать проще, но проиграть.
  2. Убедитесь, что абстракции имеют смысл. Если они слишком далеки от реальности, слишком сложно оправдать ... забыть об этом.
  3. Позвольте решению почувствовать себя естественным. Работайте над этим, пока это не произойдет. Тогда для незнакомого человека решение должно казаться настолько очевидным, что он кричит «как вы могли сделать это по-другому?».
  4. Не пытайтесь предсказать будущее. Вы не можете. Если вы попытаетесь охватить все 10 возможных случаев, вы скоро обнаружите 11-е и более, и его будет сложнее реализовать из-за предыдущих 10, которые не встречаются на практике. Сделайте его простым и легким в использовании. Программное обеспечение нуждается в изменении, но легкость адаптации (гибкость) часто намного лучше, чем попытка охватить все возможные возможные случаи.
+0

«Дайте раствору почувствовать себя естественным, работайте над ним, пока он не станет» - идеальное правило! +1 – 2013-11-30 22:36:48

0

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

Вы имеете в виду абстракцию в рамках объектно-ориентированной парадигмы программирования, где у вас есть три принципа: 'abstraction' - 'encapsulation' - 'information hiding or visibility'.

Абстракция - это процесс выбора атрибутов объекта, имеющих отношение к вашей системе и которые должны быть полностью игнорированы.

Это означает, что предел абстракции не относится столько число понятий вы определяете (Player, оружие, патроны, ...), но , что вы решили положить внутрь эти понятия.

Это в основном triage, где вы рассмотрите только концепцию, полезную для услуг, которые вам нужно определить.

Так хорошие критерии, чтобы начать писать вменяемый код может быть APIs, так как программа затмение предложить: API first.

Действительно, «Хорошие API требуют проектной итерации», то есть список объектов, которые вы упоминаете в своем вопросе, будет уточняться по мере того, как необходимый API будет уточнен.

Плюс, API должны иметь четко определенные границы компонентов и зависимости (как в «Core - Player - UI - RenderableObject -»), что означает, что очень подробный список, который вы упомянули, не может рассматриваться как длинный бесконечный список концепций, но должны быть четко сгруппированы в различные функциональные периметры (или функциональные компоненты) из прикладной архитектуры.

Поскольку API существуют для удовлетворения потребностей клиентов, вы будете хранить эти объекты только потому, что они имеют смысл для клиента. Другие объекты должны быть в «внутренних» пакетах и ​​никогда не передаваться напрямую никакими другими частями вашего приложения.

Имея это в виду, @phjr advices прекрасный смысл;)

3

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

Пример, который вы цитируете, является классическим примером недостаточной мысли о том, что на самом деле есть объекты, поскольку все они почти одинаковы - и, вероятно, лучше выражаться как один «GameObject».

Я также избегаю подкласс классификации по свойствам объекта. Для StaticGameObject и DynamicGameObject может показаться logica, но они, вероятно, лучше представлены размещением контейнеров, т. Е. Два списка для статических объектов и одно для динамического, что позволяет другой логике определять действия, а не сам объект, ответственный за контроль над чем-либо вне его объем.

Иногда сложнее выработать то, что разделяет группа вещей, которые вы хотите представлять в объекте, - но это того стоит.

Смежные вопросы