низкая связь против интуитивного проектирования объектов

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

У меня есть основной класс GameWorld и небольшой класс Missile. Когда экземпляр Ракеты взрывается, он должен повредить все корабли вокруг себя.

Я придумал два подхода к этому:

// APPROACH A:
// in class Missile
explode()
{
    for each (ship in GameWorld.getShips()) {
        if (distanceTo(ship)) <= BLAST_RADIUS) {    
            ship.dealDamage(DAMAGE);
        }
    }
}

/* creates coupling that allows Missile to call GameWorld and all of 
* it's methods, which is bad. but also keeps the entire explosion 
* process within Missile which is intuitive object design.
*/


// APPROACH B:
// in class GameWorld
update()
{
    .
    .
    .
    if (missile.position.equals(missile.destination)) {
        for each (ship in shipsArray)   {
            if (distanceTo(ship)) <= missile.BLAST_RADIUS) {    
                ship.dealDamage(missile.DAMAGE);
            }
        }
    }
    .
    .
    .
}

/* no two-way coupling from GameWorld to Missile since Missile has no 
* reference to GameWorld which is good. 
* but explosion is now something being done by the GameWorld and not 
* Missile, which is an unintuitive design. also when expanding this design 
* approach to the rest of the objects and interactions
* GameWorld can become sort of a "god class" with all smaller objects being very thin
*/

так какой подход лучше? стоит ли связывать классы, давая ссылку Missile на GameWorld, чтобы он мог использовать свои геттеры, чтобы сделать весь процесс взрыва в Missile.explode(), или лучше использовать второй менее интуитивный и менее связанный подход?

заранее спасибо.


person Rani    schedule 02.12.2016    source источник


Ответы (1)


Подход 1 имеет определенные преимущества перед вариантом 2.

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

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

Принимая во внимание вариант 2, вы более или менее отказываетесь от класса Missile. Поскольку класс GameWorld на самом деле сам выполняет большую часть/всю важную работу.

Видите ли, выбранная вами модель различает элементы (например, корабли или ракеты); и «мир», в котором существуют эти элементы. В этом смысле: в обязанности GameWorld входит отслеживание всех элементов в вашем мире. Но тогда каждый элемент отвечает за то, чтобы «делать свое дело» в конце.

person GhostCat    schedule 02.12.2016