Закон деметры и планировки

Question

Исходный код этой игры - с открытым исходным кодом, поэтому я решил проверить это. В этом я нашел что-то вроде:

// This ActionManager is basically a controller like in the MVC pattern. 
void ActionManager::HandleQueryMessage(csString xml, Client* client) 
{ 
    //check the two hands as a start. 
    psItem* item = client->GetCharacterData()->Inventory().GetInventoryItem(PSCHARACTER_SLOT_RIGHTHAND); 
    if(!item || !item->GetItemCommand().Length()) 
     item = client->GetCharacterData()->Inventory().GetInventoryItem(PSCHARACTER_SLOT_LEFTHAND); 
} 

Первая строка, чтобы получить элемент, явно нарушает закон демета. Однако, даже если он был изменен на client->GetCharacterData()->GetInventoryItem(PSCHARACTER_SLOT_RIGHTHAND);, он все равно будет нарушать закон demeter (насколько я знаю).

Что можно сделать по этому поводу? или это одно из мест, где LOD не применяется [как в моем втором примере]?

Перемещение GetInventoryItem до client класс не имеет смысла в моей точке зрения, так как клиент не имеет никакого отношения к character.

Создание оберток в классе client для всех методов xx класс character кажется излишним.

Любые мысли?

Answer 1

Как вы предлагаете себя, если вы хотите полностью следовать LOD, вы должны были бы такие функции, как ...

Item* Client::GetCharacterInventoryItem(int itemID) 
{ 
    return characterData->getInventoryItem(itemId); 
} 
/* ... */ 
Item* CharacterData::getInventoryItem(int itemID) 
{ 
    return inventory->getItem(itemId) 
} 
/* ... */ 
Item* Inventory::getItem(int itemID) 
{ 
    assert_valid_itemID(itemID); 
    return inventory_table[itemId]; 
} 

Это дополнительный косвенность стоит? Я не знаю, это зависит от вашего дела, ваших личных предпочтений и т. Д. Как показывают комментарии, LOD следует рассматривать как ориентир, а не закон. С другой стороны, в моем личном опыте, часто ломайте его, и вы попадаете в беду ... :)