UFO ET IT

한 인터페이스가 다른 인터페이스를 상속해야하는 경우

ufoet 2020. 11. 27. 21:48
반응형

한 인터페이스가 다른 인터페이스를 상속해야하는 경우


나는 이것에 대한 답을 찾을 수없는 것 같고 그것이 괜찮은 코딩 표준인지 확인하고 싶습니다. 여러 클래스에서 사용하는 인터페이스 A가 있으며 인터페이스 A가 변경되는 것을 원하지 않습니다. 인터페이스 A를 구현하는 많은 클래스에서 열거 형이 필요하다는 새로운 요구 사항을 발견했지만 모든 클래스에이 열거 형이 필요한 것은 아닙니다. 이 새로운 열거 형이 필요하지 않은 클래스가이 새로운 기능을 구현하는 것을 원하지 않습니다. 그래서 추가해야하는 새 열거 형을 포함하는 인터페이스 B를 만들었습니다. 그런 다음 인터페이스 B를 인터페이스 A 상속으로 설정했는데 이것이 내 관심사입니다. 한 인터페이스가 다른 인터페이스를 상속해도 괜찮습니까? 변경을 계속하기 위해 인터페이스 B가 상속했기 때문에 인터페이스 A 대신 인터페이스 B를 구현하기 위해 새 열거 형이 필요한 클래스를 변경했습니다.

나는 이것이 충분히 명확하기를 바랍니다 (아마 오랫동안) 그러나 누군가 나에게 이것에 대해 조언을 해줄 수 있다면 내가 옳은 일을하고 있거나 내가 잘못하고있는 것이라면 알려주세요.

감사!


인터페이스 상속은 훌륭한 도구이지만 느슨하게 관련된 동작을 집계하는 것이 아니라 인터페이스 B가 인터페이스 A를 진정으로 대체 할 수있는 경우에만 사용해야합니다.

특정 사례에 적합한 지 말하기는 어렵지만 원칙적으로 연습을 사용하는 데 잘못된 것은 없습니다. 항상 일류 API에서 볼 수 있습니다. .NET 프레임 워크에서 하나의 일반적인 예를 선택하려면 :

public interface ICollection<T> : IEnumerable<T>, IEnumerable

인터페이스가 논리적으로 쌍을 이루어야하는지 고려하고 서로 잘 작동한다고 생각되면 절대적으로 상속을 사용하십시오.

예를 살펴 보겠습니다.

public interface IScanner
{
    void Scan();
}

public interface IPrinter
{
    void Print();
}

프린터와 스캐너는 종종 각각 고유 한 기능을 가진 별도의 개체이지만이 두 장치는 종종 동일한 장치에서 쌍을 이룹니다.

public interface IPhotocopier : IScanner, IPrinter
{
    void Copy();
}

IPhotocopier는 IScanner 및 IPrinter에서 상속해야합니다. 이제 복사기를 기본 롤에 복사기로 사용할 수있을뿐 아니라 스캐너 또는 프린터 (포함)로 사용할 수 있습니다.

이제 인터페이스를 하나 더 살펴 보겠습니다.

public interface IBlender
{
    void Blend();
}

IBlender가 이전 인터페이스 (무엇이라고 부르겠습니까? IBlendingScanner?)에 의해 상속되도록 허용하는 것은 의미가 없습니다.

새 인터페이스에 적절한 이름을 지정할 수없는 경우이 인스턴스에서 상속을 사용하지 않을 수 있음을 나타낼 수 있습니다.

IDisposable과 같은 일부 인터페이스를 상속하는 것은 좋지 않은 생각입니다. 이렇게하면 새 인터페이스의 모든 구현이 일회용 리소스가없는 경우에도 처리 패턴을 구현하도록 강제하기 때문입니다.


기술적으로 말하면 인터페이스는 서로 상속되지 않습니다. IFoo에서 상속하는를 만들 때 실제로 발생 하는 일은를 IBar구현하는 모든 클래스 IFooIBar.

interface IBar
{
    void DoBar();
}

interface IFoo : IBar
{
    void DoFoo();
}

이 예에서 IFoo인터페이스에는 DoBar()메서드 가 없습니다 . 대부분의 경우 구별은 중요하지 않지만 클래스가 아닌 인터페이스에서 리플렉션을 사용할 때 물릴 수 있습니다.


확실히 인터페이스의 상속 트리를 가질 수 있으며 인터페이스를 통한 "다중 상속"도 가능합니다. 옳은 일인지 아닌지는 해당 인터페이스에 따라 다릅니다. 인터페이스 B가 인터페이스 A의 확장 또는 개선 인 경우 상속이 의미가 있지만 새 열거 형이 인터페이스 A가 표현한 개념과 거의 관련이없는 경우 두 개의 별도 인터페이스를 만들고 클래스를 갖습니다. 두 인터페이스를 모두 구현해야합니다.


IMO 이것은 정확히 올바른 접근 방식이며 문제가 없다고 생각합니다.


저는 데이터베이스가 항상 인터페이스를 보여줄 수있는 좋은 방법을 제공한다고 생각하므로 인터페이스가 다른 인터페이스를 상속해야하는지 고려할 때 다음을 살펴보십시오.

IMySqlDatabase : IDatabase
MySqlDatabase : IMySqlDatabase

IMsSqlDatabase : IDatabase
MsSqlDatabase : IMsSqlDatabase

MySqlDatabase는 IMySqlDatabase이고 IMySqlDatabase는 IDatabase입니다.

Now if you need to make changes to your IDatabase interface it's grandchildren (the conrete database classes) can reap the benefits, but you won't have to expand MySQL AND MsSQL (or perhaps even more DBMS' Interfaces). At the same time in your middle man (IMsSqlDatabase) you can still have interface features that a MySQL or Oracle DB wouldn't support.

참고URL : https://stackoverflow.com/questions/1688808/should-one-interface-inherit-another-interface

반응형