2015-04-07 7 views
2

Я строю Планировщик путей, который поможет людям спланировать путь через консольную игру RPG.Как объекты могут взаимодействовать без нарушения принципа инверсии зависимостей?

Я хочу создать таблицу, которая показывает каждый шаг по сцене. У меня на самом деле implemented a working version of this, однако это, по-видимому, ужасный дизайн ООП; он нарушает всевозможные принципы, и я считаю, что это даже не законный ООП. Проблема в том, что Table - это класс Бога.

В связи с этим я решил переписать его, пытаясь иметь в виду правильные принципы ООП. Я хочу разбить Table на несколько классов.

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

Вот главная таблица, которая будет хранить шаги игрока:

class PathTable(object): 
    ''' A path table. ''' 

    def __init__(self): 
    # table is a list of dicts, representing rows 
     self._table = [] 

    @property 
    def table(self): 
     return self._table 

    def addStep(self, step): 
     ''' Adds a step to the table. ''' 
     self._table.append(step) 

    def rmStep(self): 
     ''' Removes the last step from the table. ''' 
     try: 
      del self._table[-1] 
     except: 
      raise IndexError('Tried to remove item from an empty table.') 

Теперь, я создал InputManager, который отвечает за прием и проверку пользовательского ввода:

class InputManager(object): 
    ''' Responsible for managing user input. ''' 
    def __init__(self): 
     pass 
    def addFight(self, position): 
     ''' Add a 'fight' at table[position]. ''' 
     # table._table[position]['input'] = 'fight' 
     # Need to somehow edit a particular row in the Table. 

Однако, в настоящее время Я не знаю, как я могу получить доступ к PathTable._table[position]. Без нарушения всех принципов проектирования OO.

Это расстраивает, потому что вся работа InputManager - это доступ к PathTable. Но я не могу использовать композицию для размещения InputManager внутри PathTable, потому что это плохой дизайн.

Что такое чистый способ достичь этого?

Я новичок, и я пытаюсь учиться.

+1

Почему бы не добавить 'метод getStep' для' PathTable'? Также содержимое 'rmStep' можно просто заменить на' self._table.pop() ' –

+1

« Моя проблема в том, что мне нужны разные объекты, чтобы разговаривать друг с другом »=> выглядит как кандидат для посредника http: // en .wikipedia.org/wiki/Mediator_pattern –

ответ

1

Сначала нужно добавить поддержку для редактирования строки для шага в вашем PathTable классе:

class PathTable(object): 
    def __init__(self): 
     self._table = [] 

    ## NB : This defeats the whole point of making `_table` private 
    #@property 
    #def table(self): 
    # return self._table 

    def add_step(self, step): 
     ''' Adds a step to the table. ''' 
     self._table.append(step) 

    def rm_step(self): 
     ''' Removes the last step from the table. ''' 
     return self._table.pop() 

    def update_step(self, position, key, value): 
     self._table[position][key] = value 

Затем пройти PathTable экземпляр вашей InputManager:

class InputManager(object): 
    ''' Responsible for managing user input. ''' 
    def __init__(self, path_table): 
     self._path_table = path_table 

    def add_fight(self, position): 
     ''' Add a 'fight' at table[position]. ''' 
     self._path_table.update_step(position, 'input', 'fight') 
+0

В порядке ли это так, потому что теперь InputManager зависит от PathTable? – BBedit

+0

Как мог посредник или контроллер (это в основном то, что ваш 'InputManager') не зависит от объектов, с которыми он должен работать? Но если вы перечитаете код, 'InputManager' не будет зависеть от класса' PathTable' * *, он просто ожидает инициализации с объектом, отображающим тот же (неявный) интерфейс как «PathTable». Предполагается, что FWIW, имеющий объекты слоя UI в зависимости от объектов уровня модели домена, - как еще они могут выполнять свою работу? - то, что вы не хотите, это наличие слоя модели домена в зависимости от уровня пользовательского интерфейса. –

Смежные вопросы