ООП: Где остановиться

Question

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

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

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

Какой-нибудь вменяемый совет по этой теме?

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Вы имеете в виду абстракцию в рамках парадигмы объектно-ориентированного программирования, где в вашем распоряжении три принципа: 'абстракция' - 'инкапсуляция' - 'скрытие или видимость информации' .

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

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

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

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

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

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

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

Имея это в виду, @ phjr советы имеют смысл;)