Как лучше построить архитектуру программы

[Forrgit]

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

Хочу для танка создать отдельно класс. У меня есть 3 варианта решения(представлены на картинке), посоветуйте как лучше сделать? Танки будут различные по характеристикам, назначению и т.д., но всегда будут состоять из корпус+башня(ВАЖНО:: танк будет вращаться отдельно, корпус отдельно, у каждого своя анимация(выстрела, движения, взрыва и т.д.)).


P.s. подумывал над паттерном абстрактная фабрика(сделать абстрактный танк и для него наследников, но они по сути будут отличаться только скоростью\типом снарядов\размером). Уместен ли будет этот паттерн?

[Croessmah]

1 вариант - сразу в топку.
Танк не является ни башней, ни корпусом.
Танк состоит из корпуса и башни.
Можете унаследовать Tank от Unit.

2 вариант - тоже в топку.
Такие моноклассы не позволят
потом гибко модернизировать класс Tank.

3 вариант вполне, но friend не нужен.

[Pavia]

Forrgit
Делайте как можно проще.

Тут нет фабрик. Так как класс у вас всего один - Танк!
Вот если бы у вас было-бы несколько API и несколько мостов. Тогда можно было-бы говорить о фабрике.

Вам не нужен строитель который будет собирать этот танк так, как он состоит из двух элементов и всегда известна какими функциями они создаются.

Вариант первый не правильный. Сразу бросается повтор. Танка, танка, танк.
Танк вы предлагаете наследовать от башни и корпуса. Наследование означает многообразие. Т.е. наличие нескольких предков. Так где ещё будут использоваться башни но не у танка и где будут использоваться корпус не у танка? Ответ у вас только один танк и нет ничего более.

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