Мне нравится Responsibility-Driven Design (RDD) Wirfs-Brock, а также рекомендую этот обновленный (бесплатный документ) Responsibility-Driven Modeling подход Алистера Кокберн.

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

Если вам нравится подход, основанный на тестировании, эта статья показывает, как связать RDD с имитацией объектов и тестов.

Grow your classes bottom-up.

1) Class boundaries and semantics depend on context. Until you have a context, you don't have anything. (You may not even have a car in your example). Context is given by the user story (or use case).

2) Throw all the state and behavior suggested by the given context into one class (you could name this after the user story if you would like).

3) Use systematic Refactoring to tease this class apart into separate classes. While refactoring, use existing classes as reuse opportunities.

When you're done, you'll have a set of well-defined classes that are just enough to fulfill the needs of the given user story (and the user stories that came before).

Если верно, что «обе структуры программы одинаково хорошо справятся с задачей», то не имеет значения, какой вы выберете.

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

Атрибуты или переменные часто являются «базовыми» типами языка. Вопрос в том, что вы можете разумно абстрагировать.

Например, вы можете сократить Wheel до дескрипторов, состоящих из базовых типов, таких как целые числа, значения с плавающей запятой и строки, которые представляют характерные атрибуты любого колеса : numberOfTreads , диаметр , ширина , рекомендуемое давление , марка . Все эти атрибуты могут быть выражены с помощью базовых типов для создания объекта Wheel .

Можете ли вы сгруппировать некоторые из этих атрибутов в более абстрактную структуру, которую можно использовать повторно, независимо от Wheel ]? Я думаю так. Возможно, создайте объект Размеры с атрибутами диаметр и ширина . Тогда ваше колесо имеет связанный с ним экземпляр объекта Размеры вместо диаметра и ширины . Но вы можете подумать об использовании этого объекта Dimensions с другими объектами, которые не обязательно могут быть экземплярами Wheel .

Поднимаясь вверх по списку, вы можете уменьшить Car должен состоять из базовых типов, а также из других объектов, таких как объекты Wheel . Это разумно, потому что другие моторные и немоторные транспортные средства (например, Велосипед ) также содержат экземпляры Wheel .

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

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

Здесь есть несколько хороших ответов, но, возможно, больше, чем вы искали. Чтобы кратко ответить на ваши конкретные вопросы:

• Как мне узнать, когда сделать автомобиль объектом или колесо автомобиля объектом, если обе программные структуры достигли бы цели?

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

  Если распространить этот ответ на классы, когда поведение и / или свойства двух похожих объектов расходятся, вам понадобится новый класс.

  Итак, если вы При моделировании имитации движения с подсчетом колес может быть достаточно класса Vehicle со свойством NumberOfWheels. Если вы моделируете гоночную симуляцию с подробным описанием поверхности дороги и физики крутящего момента колес, каждое колесо, вероятно, должно быть независимым объектом.

• Как мне классифицировать и классифицировать части объекта, чтобы определить, являются ли они лучше подходят как простые атрибуты или переменные объекта, или если они действительно должны быть самим объектом?

  Ключевые различия - это идентичность и поведение. Часть с уникальным существованием - это объект. Деталь с автономным поведением требует своего собственного класса.

  Например, если вы создаете очень простую симуляцию автокатастрофы, NumberOfPassengers и DamageResistance могут быть достаточными свойствами универсального класса Vehicle. Этого было бы достаточно, чтобы сказать вам, была ли машина разбита, а пассажиры выжили. Если ваше моделирование более детализировано, возможно, вы хотите узнать, как далеко каждый пассажир был отброшен при лобовом столкновении, тогда вам понадобится класс Passenger и отдельные объекты Passenger в каждом Транспортном средстве.