인터페이스와 관련된 시뮬레이션에 대한 잘못된 OOP 설계입니까?

나는 뱀파이어, 늑대, 인간 및 트럭을 시뮬레이션하기 위해 내 자신의 작은 OOP 프로그램을 설계하고 있으며 인터페이스에 대한 내 자신의 제한된 이해를 구현하려고합니다.

( 여전히 추상화하고 있으며 아직 코드 구현이 없으므로 OOP 디자인의 문제입니다 ... 생각합니다!)

이 클래스들 사이 에서 '공통 행동' 을 찾고 인터페이스 로 구현하는 것이 맞 습니까?

예를 들어, 뱀파이어와 늑대는 물린 ... 물린 인터페이스가 있어야합니까?

public class Vampire : Villain, IBite, IMove, IAttack

트럭과 마찬가지로 ...

public class Truck : Vehicle, IMove

그리고 인간을 위해 ...

public class Man : Human, IMove, IDead

내 생각이 바로 여기에 있습니까? (당신의 도움을 주셔서 감사합니다)

object-oriented interfaces

— 사용자 3396486
소스

동물, 채소 및 미네랄은 응용 프로그램 구현을위한 좋은 예를 거의 만들어 내지 않습니다. 실제 구현은 같은, 일반적으로 더 추상적이다 IEnumerable, IEquatable등

— 로버트 하비

당신은 하나의 언급 당신의 객체가하려고 무엇을 할 ( "물린") 소프트웨어에 있습니다. 소프트웨어는 일반적으로 특성을 기반으로 한 객체 모델을 기반으로 무언가 를 수행 하도록 설계 되어 어디에서나 앞서지 않습니다.

— tofro

@tofro 저의 의도는 IBite가 (1) 다른 사람의 '생명 / 에너지'수준 감소 (2) '혈액'그래픽의 출현 또는 호출 및 (3) 시뮬레이션 정적 업데이트와 관련하여 동작을 구현하는 여러 가지 방법을 포함한다는 것입니다. 데이터 (예 : NoOfBites). 인터페이스가 다양한 메소드 동작을 구현하는 데 가장 잘 사용된다는 것을 이해할 수 있다고 생각합니다.

— user3396486

Human, Vampire 및 Vehicle 클래스는 이미 IMove 인터페이스를 구현하지 않습니까? 서브 클래스가이를 너무 명시 적으로 구현하도록해야하는 이유는 무엇입니까?

— Pierre Arlaud

이 모든 인터페이스가 정말로 필요합니까? 운 좋게도 파이썬에서는 이런 것들이 필요하지 않습니다. ehich는 정말 상쾌한 변화였습니다 (제 첫 언어는 Object Pascal입니다). 또한 경우에 따라 가상 방법이 더 나은 솔루션 일 수 있습니다.

— Ajasja

답변:

일반적으로 clasess의 공통 특성에 대한 인터페이스를 원합니다.

나는 코멘트에서 @Robert Harvey와 반 동의한다. 그는 보통 인터페이스가 클래스의 더 추상적 인 기능을 나타낸다고 말했다. 그럼에도 불구하고, 나는 더 구체적인 예에서 시작하여 추상적이라고 생각하기에 좋은 방법을 찾았습니다.

귀하의 예는 기술적으로 정확하지만 (예, 뱀파이어와 늑대가 물기 때문에 이에 대한 인터페이스를 가질 수 있음) 관련성의 문제가 있습니다. 각 개체에는 수천 가지 특성이 있습니다 (예 : 동물은 모피를 가지고 있거나 수영 할 수 있으며 나무를 등반 할 수있는 등). 당신은 그들 모두를위한 인터페이스를 만들 것입니까? 가능성이 매우 낮습니다.

일반적으로 응용 프로그램에서 전체적으로 그룹화 할 수있는 인터페이스가 필요합니다. 예를 들어 게임을 제작하는 경우 IMove 개체 배열을 만들고 해당 위치를 업데이트 할 수 있습니다. 그렇게하고 싶지 않다면 IMove 인터페이스를 갖는 것은 쓸모가 없습니다.

요점은 오버 엔지니어링하지 마십시오. 해당 인터페이스를 어떻게 사용할 것인지 생각해야하며, 공통된 메소드를 갖는 2 개의 클래스는 인터페이스를 작성하기에 충분한 이유가 아닙니다.

— 폴 92
소스

각 객체에 수천 개의 속성 이 없기를 바랍니다 .

— gardenhead

oop 속성이 아닌 문법 속성 / 특성 (열거 가능, 비교 가능 등) : D. 단어의 나쁜 선택.

— Paul92

유용한 인터페이스가 사용할 인터페이스라는 점에 주목할 가치가 있습니다. 예를 들어, IBite특별히 유용하지는 않지만 IAttack공격을하는 모든 작업을 IUpdate수행하거나 모든 것에 대한 업데이트를 실행하거나 IPhysicsEnabled물리를 적용 할 수 있도록 원하는 경우가 있습니다.

— anaximander

이 답변은 몇 가지 좋은 점을 제기합니다. 마지막 단락은 그것을 잘 요약합니다. 최소한 제공된 세부 수준으로 할 수 있습니다.

— 궤도에서 가벼움

그룹화 공통 메소드는 추상 클래스에 더 적합합니다. 일부 오브젝트에 대해 동일한 구현을 그룹화하지 않고 계약을 구현하는 계약자를 존중해야하는 계약을 설계하기위한 인터페이스가 작성됩니다.

— Walfrat

단일 메소드 인터페이스를 여러 개 작성하는 것 같습니다 . 이것은 겉으로는 괜찮지 만 인터페이스를 구현하는 클래스가 인터페이스를 소유하지 않는다는 것을 명심하십시오. 그것들은 그것들을 사용하는 클라이언트가 소유합니다. 클라이언트는 무언가가 움직여 공격 할 수 있어야하는지 결정합니다.

나는이있는 경우 Combat로모그래퍼 클래스를 fight()방법, 그 방법은 가능성이 모두를 호출 할 필요가 move()와 attack()같은 객체를. 즉 강하게 필요 제안 ICombatant인터페이스를 fight()호출 할 수 move()와 attack()통해있다. 물체를 fight()가져 와서 움직일 수 있는지 확인 하는 것보다 깨끗 IAttack합니다 IMove.

그렇다고 IMove IAttack인터페이스 를 가질 수 없다는 의미는 아닙니다 . 고객이 필요로하지 않고서도 제작하지 않기를 바랍니다. 반대로, 클라이언트가 객체를 이동시키고 공격 ICombatant할 필요가 없다면 필요하지 않습니다.

사람들이 다음 예제를 좋아하기 때문에 인터페이스를 보는이 간단한 방법은 종종 사라집니다. 우리가 처음 접하는 인터페이스는 라이브러리에 있습니다. 불행히도 라이브러리는 클라이언트가 무엇인지 전혀 모릅니다. 따라서 고객의 요구 만 추측 할 수 있습니다. 따라야 할 가장 좋은 예는 아닙니다.

— 설탕에 절인 _ 오렌지
소스

젠장. 게임은 OOP를 사용하고 설명하는 정말 좋은 방법 인 것 같습니다.

— JeffO

@JeffO는 실제로 상당히 큰 게임을 구현하고 OOP가 핫 엉망이고 구성 요소 기반 시스템 또는 데이터 지향 디자인을 사용하는 것이 좋습니다.

— Darkhogg

"인터페이스는 인터페이스를 사용하는 클라이언트가 소유합니다"

— Tibos

관련 ericlippert.com/2015/04/27/wizards-and-warriors-part-one

— Jared Smith

라이브러리와 응용 프로그램의 차이점에 대해 +1, 나는 종종 (너무 많은 : : /) 다른 것에 맞지 않는 많은 것들을 읽습니다.

— Walfrat

서로 다른 기능 조합을 가진 객체 컬렉션을 갖는 것이 일반적인지 여부와 코드가 이를 지원하는 컬렉션 내에서 해당 항목에 대해 작업을 수행 할 것인지 고려 하십시오 . 그렇다면 어떤 동작을 유용하게 지원하지 않는 객체에 대해 합리적인 "기본 동작"이있을 경우, 유용하게 동작 할 수있는 것뿐만 아니라 광범위한 클래스로 인터페이스를 구현하는 것이 도움이 될 수 있습니다.

예를 들어, 몇 종류의 생물 만이 Woozles를 가질 수 있고 그러한 생물이 NumerOfWoozles속성 을 갖기를 원한다고 가정하십시오 . 그러한 속성이 Woozles를 가질 수있는 생물체에 의해서만 구현 된 인터페이스에 있었다면, 혼합 유형의 생물체 모음이 보유한 총 Woozles를 찾고자하는 코드는 다음과 같이 말해야합니다.

int total = 0;
foreach (object it in creatures)
{
   IWoozleCountable w = trycast(it, IWoozleCountable);
   if (w != null) total += w.WoozleCount;
}

그러나 WoozleCount가 Creature / ICreature의 멤버 인 경우, 항상 0을 반환하는 Creature의 기본 WoozleCount 구현을 무시하는 하위 유형은 거의 없지만 코드를 다음과 같이 단순화 할 수 있습니다.

int total = 0;
foreach (ICreature it in creatures)
   total += it.WoozleCount;

어떤 사람들은 모든 생물이 소수의 하위 유형에만 유용한 WoozleCount 속성을 구현하도록하는 아이디어에 혼란을 겪을 수도 있지만, 해당 유형의 것으로 알려진 항목에 유용한 지 여부에 관계없이 모든 유형에 대해 의미 가 있습니다. "주방 싱크"인터페이스는 trycast 연산자보다 코드 냄새가 적은 것으로 간주합니다.

— 슈퍼 캣
소스