디자인 패턴 - 인터페이스 분리

Question

모든 레슬러가 서로 싸우는 레슬링 게임을 개발했다고 가정합니다.

public interface IWrestler 
{ 
    void Attack(); 
} 

public class Sumo : IWrestler 
{ 
    public Sumo() 
    { 
    } 

    public void Attack() 
    { 
     Console.Write("Sumo attacked the opponent..."); 
    } 
} 

public class Shaolin : IWrestler 
{ 
    //------ etc. 
} 

올해 내가 (이전에 생각하지 않은) 무기를 수행하기 위해 선수를 원한다 :

그래서 나는 다음과 같은 클래스와 인터페이스를 디자인했다.

많은 수의 클래스를 이미 생성했다고 가정합니다.

이 문제를 해결하기 위해 어떤 디자인 패턴을 사용할 수 있습니까? 또는 지금이 문제를 어떻게 해결해야합니까?

처음에는이 문제를 방지하기 위해 어떤 디자인 패턴을 사용할 수 있습니까?

Answer 1

나는이 문제에 대한 디자인 패턴에 너무 깊이 잠기지 않을 것이라고 믿습니다. 손에 들고있는 디자인 문제에서 저는 무기를 들고있는 레슬러가 레슬러가 아니라 새로운 인터페이스로 대표되는 전사 인 것을 자연스럽게 말할 것입니다. Sumo 막대기로 무장되어있는 경우와 의견에 대해서는

public interface IWrestler 
{ 
    void Attack(); 
}  
public interface IWarrior : IWrestler 
{ 
    void WeaponedAttack(); 
} 
// let's assume that Sumo's don't carry weapons 
public class Sumo : IWrestler 
{ 
    public void Attack() 
    { 
     Console.Write("Sumo attacked the opponent..."); 
    } 
} 
//..but Shaolin do: 
public class Shaolin : IWarrior 
{ 
    public void Attack() 
    { 
     Console.Write("Shaolin attacked the opponent as a wrestler..."); 
    } 

    public void WeaponedAttack() 
    { 
     Console.Write("Shaolin attacked the opponent as a warrior..."); 
    } 
} 

: 이전 버전과의 호환성을 위해, 우리는 또한 선수가 될 모든 전사를 요구할 수 있습니다 나는 막대기로 Sumo 또한 전사로 간주 될 수 있음을 추측; 대신 IWarrior을 구현하고 WeaponedAttack을 사용하여 막대기로 공격하십시오. 스틱이 방어를 위해 독점적으로 있지 않는 한 (그러나 인터페이스의 일부인 것처럼 보이지는 않지만, 공격자가 상대방을 어떻게 보는지 또는 그 반대인지는 알 수 없습니다).

IAttacker 및 IDefender의 인터페이스가 있어야하며 여기에 IAttacker.Attack(IDefender)과 IDefender.BeingAttacked(IAttacker)이 있고 각 클래스에서 두 가지를 모두 구현해야합니까? 그런 식으로 누가 누가 이길지 결정할 수있는 일종의 점수 매김 메커니즘이 될 수 있습니다. (단지 생각을 던지기 ..)

Answer 2

처음에는이 문제를 방지하기 위해 어떤 디자인 패턴을 사용할 수 있습니까?

Visitor을 살펴보십시오. 이러한 구조를 수정하지 않고도 기존의 객체 구조에 새로운 작업을 추가 할 수 있습니다.

Answer 3

에 어떤 디자인 패턴을 사용할 수 있습니까? 또는 지금 이이 문제를 어떻게 해결해야합니까?

이미 설계된 클래스의 경우이 문제를 해결하는 데 도움이되는 정적 언어 이외의 정적 언어로 마술처럼 적용될 수있는 디자인 패턴이 없습니다. Iweapon 인터페이스와 무기 목록에 대한 참조를 모든 레슬러에게 추가해야합니다.

처음에는이 문제를 방지하기 위해 어떤 디자인 패턴을 사용할 수 있습니까?

이렇게하면 안됩니다. 당신은 당신의 수업을 잘 설계했습니다. 변화의 패턴을 인식하고 당신의 욕구를 지원하는 것이 중요합니다. 그렇지 않으면 모든 가능한 경우를 생각하면 시간 낭비 일뿐입니다.

Answer 4

내가 묻는 질문은 실제로 스모 클래스 또는 IWrestler 인터페이스를 시작할지 여부입니다.

IWrestler는 공격 해결, 내부 통계 확인 등 여러 가지 일에 책임이 있습니다. 이러한 종류의 일은 Single Responsibility Principle을 위반하는 것입니다.

Iwrestler는 완료 될 때까지 많은 방법을 사용하게 될 것이며 그 중 일부는 서로 거의 관련이 없을 것입니다. 그것은 당신이 진흙 투성이 방지 패턴으로 떠드는 또 다른 징후입니다.

공격과 방어가 서로 관련되어 있다는 사실은 다른 클래스 (또는 그 이상)가 거기에 숨어있어 둘 사이의 중재의 책임이 있음을 나타냅니다.

마지막 제안으로서 데이터 구조 기반 관점이 아니라 사용자와의 상호 작용 관점에서 이것을 고려하는 것이 가치가 있습니다. 사용자 입력에서 최종 결과까지의 데이터 흐름을 모델링하면 언뜻보기에는 명확하지 않은 몇 가지 가능한 디자인을 제안 할 수 있습니다. 고전적인 디자인 패턴이 실제로 빛나기 시작한다는 사실을이 관점에서 바라 보았을 때입니다.