ООП: где прекратить абстрагирование
Где вы проводите черту, чтобы перестать делать абстракции и начать писать разумный код? Существует множество примеров «корпоративного кода», таких как программа «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
и т.д ... и это может превратиться в кошмар. Это можно довести до своего логического предела, так же как функциональное программирование можно довести до предела, когда вы можете создать язык только с переменными, приложением функций и определениями анонимных функций (хотя я должен признать, что это немного более элегантно) ...
Есть какие-нибудь разумные советы по этой теме?
Ответы 3
- ЯГНИ (Вам это не нужно). Не создавайте абстракций, которые вы не видите немедленного использования или по разумной причине. Таким образом, у вас есть простая вещь, которая может стать более сложной, вместо сложной вещи, которую вы пытались бы упростить, но проиграли.
- Убедитесь, что абстракции имеют смысл. Если они слишком далеки от реальности, их сложно оправдать ... забудьте об этом.
- Пусть раствор будет казаться естественным. Работайте над этим, пока это не произойдет. Тогда для незнакомого человека решение должно показаться настолько очевидным, что он кричит: «Как ты мог это сделать по-другому?».
- Не пытайтесь предсказывать будущее. Вы не можете. Если вы попытаетесь охватить все 10 возможных случаев, вы скоро обнаружите 11-й и более, и реализовать его будет сложнее из-за предыдущих 10, не встречающихся на практике. Сделайте это простым и легким для адаптации. Программное обеспечение необходимо изменить, но простота адаптации (гибкость) часто является гораздо лучшей стратегией, чем попытки заранее охватить все возможные случаи.
Я считаю, что критерии могут быть выведены из четкого определения того, что такое абстракция.
Вы имеете в виду абстракцию в рамках парадигмы объектно-ориентированного программирования, где в вашем распоряжении три принципа: 'абстракция' - 'инкапсуляция' - 'скрытие или видимость информации'.
Абстракция - это процесс выбора, какие атрибуты объекта имеют отношение к вашей системе, а какие необходимо полностью игнорировать.
Это означает, что предел абстракции касается не столько количество концепций, которые вы определяете (игрок, оружие, пули, ...), но что вы решите положить внутрь этих концепций.
По сути, это сортировка, где вы будете рассматривать только концептуально, что полезно для сервисов, которые вам нужно определить.
Итак, Хорошим критерием для начала написания разумного кода могут быть API, как предлагает программа eclipse: API в первую очередь.
В самом деле, «Хорошие API требуют итерации дизайна», это означает, что список объектов, которые вы упоминаете в своем вопросе, будет уточняться по мере уточнения необходимого API.
Кроме того, API означает наличие четко определенных границ компонентов и зависимостей (например, «Core - Player - vs. UI - RenderableObject -»), что означает, что очень подробный список, который вы упоминаете, нельзя рассматривать как длинный бесконечный список концепций, но должны быть четко сгруппированы в разные функциональные периметры (или функциональные компоненты) из прикладной архитектуры.
Поскольку API существуют для обслуживания потребностей клиентов, вы сохраните эти объекты только потому, что они имеют смысл для клиента. Остальные объекты должны находиться во «внутренних» пакетах и никогда не должны напрямую ссылаться на какие-либо другие части вашего приложения.
Имея это в виду, @phjr советы имеет смысл;)
Возможно, этот вопрос должен быть с чего начать абстрагирование.
Пример, который вы цитируете, является классическим примером недостаточного обдумывания того, что на самом деле представляют собой объекты, поскольку все они в значительной степени одинаковы - и, вероятно, его лучше было бы выразить как один «GameObject».
Я также избегаю подкласса по свойствам объекта. Для StaticGameObject и DynamicGameObject могут показаться логичными, но, вероятно, лучше представлены размещением контейнера, то есть двумя списками, один для статических объектов, а другой для динамических, что позволяет другой логике определять действия, а не сам объект, отвечающий за управление чем-то вне его. объем.
Иногда сложнее понять, что разделяет группа вещей, которую вы хотите представить в объекте, но это того стоит.
«Пусть раствор будет казаться естественным. Работайте над ним, пока он не станет» - идеальное правило! +1