このゲームのソースコードはオープンソースなので、私はそれを調べることにしました。その中で、私のようなものを見つけました:demeterとplaneshiftの法律
// 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);
に変更されたとしても、それは(私が知る限り)デメテルの法則に違反することになります。
これについて何ができるのですか?それともLODが適用されないこの場所の1つですか?
クライアントはcharacter
とは関係がないため、GetInventoryItem
をclient
クラスに移動することは私の視点では意味がありません。
client
クラスのラッパーをすべてのxxメソッドに対して作成すると、character
クラスは過剰なようです。
どのような考えですか?この追加の間接はそれだけの価値
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];
}
"法の法則"は本当に "Demeterのガイドライン"です。この質問は、スタックオーバーフローにはあまりにも主観的です。なぜなら、人々がいくつかの機能を設計する方法をコーディングスタイルの問題にしているからです。あなたは、高品質のオープンソースゲームのコードベースを確認したい場合は、ドゥーム3を試してみてください。http://fabiensanglard.net/doom3/ –
@DietrichEppプレーンシフトのソースは、サーバー側のカントーです。運命はクライアントだけです。 – James
これは間違っています。 Doom 3のソースはクライアントだけではありません。 –