C #의 is연산자와 Java의 instanceof연산자를 사용하면 개체 인스턴스가 구현 한 인터페이스 (또는 기본 클래스의 기본 클래스)를 분기 할 수 있습니다.

인터페이스가 제공하는 기능을 기반으로 고수준 분기에이 기능을 사용하는 것이 적절합니까?

아니면 기본 클래스가 객체가 가진 기능을 설명하기위한 인터페이스를 제공하기 위해 부울 변수를 제공해야합니까?

예:

if (account is IResetsPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

vs.

if (account.CanResetPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

기능 식별을 위해 인터페이스 구현을 사용하는 데있어 함정이 있습니까?

이 예는 바로 그 예입니다. 더 일반적인 응용 프로그램이 궁금합니다.

가능한 경우 다운 캐스팅을 피하는 것이 가장 좋다는 경고에 따라 첫 번째 형식이 두 가지 이유로 선호됩니다.

1. 당신은 타입 시스템이 당신을 위해 일하게하고 있습니다. 첫 번째 예에서 is화재가 발생하면 다운 캐스트가 작동합니다. 두 번째 양식에서는 구현하는 객체 만 IResetsPassword해당 속성에 대해 true를 반환 하도록 수동으로 확인해야 합니다.
2. 깨지기 쉬운 기본 클래스. 추가하려는 모든 인터페이스의 기본 클래스 / 인터페이스에 속성을 추가해야합니다. 번거롭고 오류가 발생하기 쉽습니다.

그렇다고 이러한 문제를 어느 정도 개선 할 수는 없습니다. 예를 들어, 기본 클래스에 포함을 확인할 수있는 공개 된 인터페이스 세트가있을 수 있습니다. 그러나 실제로는 기존 유형 시스템의 일부를 중복으로 구현하는 것이 실제로 수동입니다.

BTW 저의 자연스러운 선호는 상속에 대한 구성이지만 대부분 국가와 관련이 있습니다. 인터페이스 상속은 일반적으로 나쁘지 않습니다. 또한 가난한 사람의 유형 계층 구조를 구현하는 경우 컴파일러가 도움을 줄 수 있으므로 이미 존재하는 계층 구조를 사용하는 것이 좋습니다.

객체의 기능은 구현하는 인터페이스에 의해 독점적으로 식별되어야합니까?

객체 기능을 전혀 식별하지 않아야합니다.

객체를 사용하는 클라이언트는 객체의 작동 방식에 대해 알 필요가 없습니다. 클라이언트는 객체에게 지시 할 수있는 것만 알아야합니다. 일단 말한 객체는 클라이언트 문제가 아닙니다.

오히려

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

또는

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

치다

account.ResetPassword();

또는

account.ResetPassword(authority);

account이것이 작동하는지 이미 알고 있기 때문 입니다. 왜 물어봐? 원하는 것을 말하고 원하는 일을하게하십시오.

이것이 다른 문제이기 때문에 클라이언트가 작동했는지 여부를 신경 쓰지 않는 방식으로 수행했다고 상상해보십시오. 클라이언트 작업은 단지 시도를하는 것이 었습니다. 이제 끝났고 처리해야 할 다른 것들이 있습니다. 이 스타일에는 많은 이름이 있지만 내가 가장 좋아하는 이름은 말하지 마십시오 .

클라이언트를 작성할 때 모든 것을 추적해야한다고 생각하기 때문에 매우 유혹적입니다. 그렇게하면 물건을 안으로 뒤집습니다. 당신의 무지를 평가하십시오. 세부 사항을 밀고 물체가 처리하도록하십시오. 덜 알수록 좋습니다.

배경

상속은 객체 지향 프로그래밍의 목적을 제공하는 강력한 도구입니다. 그러나 모든 문제를 우아하게 해결하지는 않습니다. 때로는 다른 솔루션이 더 좋습니다.

초기 컴퓨터 과학 수업 (CS 학위가 있다고 가정)을 다시 생각하면 고객이 소프트웨어에서 원하는 것을 나타내는 단락을 제공하는 교수를 기억할 수 있습니다. 당신의 임무는 단락을 읽고 배우와 행동을 식별하고 클래스와 방법에 대한 대략적인 개요를 없애는 것입니다. 중요한 것처럼 보이지만 그렇지 않은 부스트 ​​리드가있을 것입니다. 요구 사항을 잘못 해석 할 가능성도 매우 높습니다.

이것은 우리 중 가장 경험이 많은 사람조차도 요구 사항을 올바르게 식별하고이를 기계 언어로 번역하는 잘못된 기술입니다.

당신의 질문

당신이 작성한 것에 근거하여, 당신이 수업이 수행 할 수있는 선택적인 행동의 일반적인 경우를 오해하고 있다고 생각합니다. 예, 귀하의 코드는 단지 예일 뿐이며 일반적인 경우에 관심이 있습니다. 그러나 객체의 특정 하위 유형 이 작업을 수행 할 수 있지만 다른 하위 유형은 수행 할 수없는 상황을 처리하는 방법을 알고 싶어하는 것 같습니다 .

account계정 유형 과 같은 객체 가 OO 언어의 유형으로 변환되는 것은 아닙니다. 인간 언어의 "유형"이 항상 "클래스"를 의미하는 것은 아닙니다. 계정의 맥락에서 "유형"은 "권한 세트"와 더 밀접한 관련이있을 수 있습니다. 사용자 계정을 사용하여 작업을 수행하려고하지만 해당 계정에서 해당 작업을 수행하거나 수행하지 못할 수 있습니다. 상속을 사용하는 대신 대리자 또는 보안 토큰을 사용합니다.

내 솔루션

수행 할 수있는 몇 가지 선택적 조치가있는 계정 클래스를 고려하십시오. 상속을 통해 "액션 X를 수행 할 수 있음"을 정의하는 대신 계정이 대리자 개체 (암호 재설정 기, 양식 제출자 등) 또는 액세스 토큰을 반환하지 않는 이유는 무엇입니까?

account.getPasswordResetter().doAction();
account.getFormSubmitter().doAction(view.getContents());

AccountManager.resetPassword(account, account.getAccessToken());

마지막 옵션에 대한 이점이 제가 사용하려는 경우 내 누군가가 다시 계정 자격 증명을 다른 사람의 비밀번호를?

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

시스템이 더 유연 할뿐만 아니라 타입 캐스트를 제거했을뿐만 아니라 디자인이 더욱 표현력이 좋습니다. 나는 이것을 읽고 그것이 무엇을하고 있고 어떻게 사용되는지 쉽게 이해할 수 있습니다.

TL; DR : 이것은 XY 문제 처럼 읽습니다 . 일반적으로 차선책 인 두 가지 옵션에 직면했을 때 한 걸음 물러서서 "내가 실제로 무엇 을 성취하려고 노력하고 있습니까?" 타입 캐스트를 완전히 제거 하시겠습니까? "

빌 벤너 (Bill Venner) 는 귀하의 접근 방식은 절대적으로 훌륭하다고 말합니다 . '인스턴스 사용시기'섹션으로 이동하십시오. 특정 동작 만 구현하는 특정 유형 / 인터페이스로 다운 캐스팅하므로 선택에 대한 올바른 선택입니다.

그러나 다른 접근 방식을 사용하려면 야크를 면도하는 여러 가지 방법이 있습니다.

다형성 접근법이 있습니다. 모든 계정에 비밀번호가 있다고 주장 할 수 있으므로 모든 계정은 최소한 비밀번호 재설정을 시도 할 수 있어야합니다. 즉, 기본 계정 클래스에는 resetPassword()모든 계정이 고유 한 방식으로 구현 되는 방법이 있어야합니다 . 문제는 기능이 없을 때 그 방법이 어떻게 동작해야 하는가입니다.

암호를 재설정했는지 여부에 관계없이 빈 공간을 반환하고 자동으로 완료 할 수 있습니다. 암호를 재설정하지 않으면 메시지를 내부적으로 인쇄해야 할 수도 있습니다. 가장 좋은 생각은 아닙니다.

재설정이 성공했는지 여부를 나타내는 부울을 반환 할 수 있습니다. 부울을 켜면 암호 재설정 실패와 관련 될 수 있습니다.

비밀번호 재설정 시도 결과를 나타내는 문자열을 리턴 할 수 있습니다. 이 문자열은 재설정이 실패한 이유와 출력에 대한 자세한 정보를 제공 할 수 있습니다.

더 자세한 내용을 전달하고 이전의 모든 반환 요소를 결합하는 ResetResult 개체를 반환 할 수 있습니다.

해당 기능이없는 계정을 재설정하려고하면 void를 반환하고 대신 예외를 throw 할 수 있습니다 (다양한 이유로 정상적인 흐름 제어에 예외 처리를 사용하는 것은 좋지 않기 때문에 수행하지 마십시오).

일치하는 canResetPassword()메소드 를 갖는 것은 세계적으로 최악의 것처럼 보이지 않을 수 있습니다. 개념적으로 작성된 것은 클래스에 내장 된 정적 기능입니다. 그러나 이는 접근 방식이 역동적이고 canResetPassword()변경 될 수 있음을 시사하기 때문에 메소드 접근 방식이 왜 나쁜 아이디어인지에 대한 단서입니다 . 다른 곳에서 언급했듯이 허락을 구하기보다는 말하십시오.

상속에 대한 컴포지션은 옵션이 될 수 있습니다. 최종 passwordResetter필드 (또는 동등한 getter) 및 호출하기 전에 null을 확인할 수있는 동등한 클래스가있을 수 있습니다. 권한을 요청하는 것과 약간 비슷하지만 최종성은 유추 된 동적 특성을 피할 수 있습니다.

기능을 자체 클래스로 외부화하여 매개 변수로 고려하여 조치를 취할 수 있다고 생각할 수도 있습니다 (예 resetter.reset(account):). 이는 종종 나쁜 습관입니다.

기능이있는 언어에서는 믹스 인 또는 특성을 사용할 수 있지만 해당 기능의 존재 여부를 확인하기 시작한 위치에있게됩니다.

이 구체적인 예를 들어, " 암호를 재설정 할 수 있습니다 " 내가 상속을 통해 구성 사용하는 것이 좋습니다 것 (이 경우, 인터페이스 / 계약의 상속). 왜냐하면 이렇게함으로써 :

class Foo : IResetsPassword {
    //...
}

'클래스' 에서 비밀번호를 재설정 할 수 있도록 즉시 (컴파일 타임에) 지정 합니다 . 그러나 시나리오에서 기능의 존재가 조건 적이며 다른 것에 의존하는 경우 더 이상 컴파일 타임에 항목을 지정할 수 없습니다. 그런 다음이 작업을 수행하는 것이 좋습니다.

class Foo {

    PasswordResetter passwordResetter;

}

이제 런타임시이 myFoo.passwordResetter != null작업을 수행하기 전에 확인할 수 있습니다 . 더 많은 것을 분리하고 더 많은 기능을 추가하려는 경우 다음을 수행 할 수 있습니다.

class Foo {
    //... foo stuff
}

class PasswordResetOperation {
    bool Execute(Foo foo) { ... }
}

class SendMailOperation {
    bool Execute(Foo foo) { ... }
}

//...and you follow this pattern for each new capability...

최신 정보

OP의 다른 답변과 의견을 읽은 후 질문이 구성 솔루션에 관한 것이 아니라는 것을 이해했습니다. 따라서 다음과 같은 시나리오에서 일반적인 객체 기능을 더 잘 식별하는 방법에 대한 질문입니다.

class BaseAccount {
    //...
}
class GuestAccount : BaseAccount {
    //...
}
class UserAccount : BaseAccount, IMyPasswordReset, IEditPosts {
    //...
}
class AdminAccount : BaseAccount, IPasswordReset, IEditPosts, ISendMail {
    //...
}

//Capabilities

interface IMyPasswordReset {
    bool ResetPassword();
}

interface IPasswordReset {
    bool ResetPassword(UserAccount userAcc);
}

interface IEditPosts {
    bool EditPost(long postId, ...);
}

interface ISendMail {
    bool SendMail(string from, string to, ...);
}

이제 언급 된 모든 옵션을 분석하려고합니다.

OP 두 번째 예 :

if (account.CanResetPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

이 코드가 기본 계정 클래스를 받고 있다고 가정합니다 (예 : BaseAccount내 예). 기본 클래스에 부울을 삽입하여 전혀 의미가없는 코드로 부울을 삽입하기 때문에 이것은 좋지 않습니다.

OP 첫 번째 예 :

if (account is IResetsPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

질문에 대답하기 위해 이것은 이전 옵션보다 더 적합하지만 구현에 따라 L 원칙을 깨뜨릴 수 있으며 아마도 코드를 통해 확산되고 추가 유지 관리가 더 어려워 질 것입니다.

설탕에 절인 오렌지의 anser :

account.ResetPassword(authority);

이 ResetPassword메소드가 BaseAccount클래스에 삽입되면 OP의 두 번째 예제와 같이 부적절한 클래스 코드로 기본 클래스를 오염시킵니다.

눈사람의 답변 :

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

이것은 좋은 솔루션이지만 기능이 동적이며 시간이 지남에 따라 변경 될 수 있음을 고려합니다. 그러나 OP에서 여러 의견을 읽은 후에는 여기서 이야기가 다형성 및 정적으로 정의 된 클래스에 관한 것이라고 생각합니다 (계정의 예는 동적 시나리오를 직관적으로 지적하지만). EG :이 AccountManager예에서 권한 확인은 DB에 대한 쿼리입니다. OP 질문에서 검사는 객체를 캐스팅하려는 시도입니다.

나에게서 또 다른 제안 :

높은 수준의 분기에 템플릿 방법 패턴을 사용하십시오. 언급 된 클래스 계층은 그대로 유지됩니다. 캐스트 및 기본 클래스를 오염시키는 부적절한 속성 / 메소드를 피하기 위해 객체에 대해 더 적절한 처리기를 만듭니다.

//Template method
class BaseAccountOperation {

    BaseAccount account;

    void Execute() {

        //... some processing

        TryResetPassword();

        //... some processing

        TrySendMail();

        //... some processing
    }

    void TryResetPassword() {
        Print("Not allowed to reset password with this account type!");
    }

    void TrySendMail() {
        Print("Not allowed to reset password with this account type!");
    }
}

class UserAccountOperation : BaseAccountOperation {

    UserAccount userAccount;

    void TryResetPassword() {
        account.ResetPassword(...);
    }

}

class AdminAccountOperation : BaseAccountOperation {

    AdminAccount adminAccount;

    override void TryResetPassword() {
        account.ResetPassword(...);
    }

    void TrySendMail() {
        account.SendMail(...);
    }
}

사전 / 해시 테이블을 사용하여 작업을 적절한 계정 클래스에 바인딩하거나 확장 메서드를 사용하여 런타임 작업을 수행하거나 dynamic키워드를 사용 하거나 마지막 옵션으로 계정 개체를 작업에 전달하기 위해 하나의 캐스트 만 사용할 수 있습니다 . 이 경우 캐스트 수는 작업 시작시 단 하나입니다).

제시 한 옵션 중 어느 것도 좋은 OO가 아닙니다. 객체 유형에 대해 if 문을 작성하는 경우 OO를 잘못 수행했을 가능성이 높습니다.

interface IAccount {
  bool CanResetPassword();

  void ResetPassword();

  // Other Account operations as needed
}

public class Resetable : IAccount {
  public bool CanResetPassword() {
    return true;
  }

  public void ResetPassword() {
    /* RESET PASSWORD */
  }
}

public class NotResetable : IAccount {
  public bool CanResetPassword() {
    return false;
  }

  public void ResetPassword() {
    Print("Not allowed to reset password with this account type!");}
  }

원래 코드가 수행 한 작업과 일치하도록이 예제를 수정했습니다. 일부 의견에 따르면 사람들이 이것이 '올바른'특정 코드인지 여부에 매달리고있는 것 같습니다. 이것이이 예의 요점이 아닙니다. 전체 다형성 오버로딩은 본질적으로 객체의 유형에 따라 다른 로직 구현을 조건부로 실행하는 것입니다. 두 예제 모두에서 수행하는 작업은 언어에서 제공하는 기능을 손으로 방해하는 것입니다. 간단히 말해서 하위 유형을 제거하고 계정 유형의 부울 속성으로 재설정하는 기능을 사용할 수 있습니다 (하위 유형의 다른 기능은 무시).

디자인에 대한 더 넓은 견해가 없다면 이것이 특정 시스템에 적합한 솔루션인지 여부를 알 수는 없습니다. 그것은 간단하고 그것이 당신이하고있는 일에 효과적이라면 누군가가 ResetPassword ()를 호출하기 전에 CanResetPassword ()를 확인하지 않으면 다시 생각할 필요가 없습니다. 부울을 리턴하거나 자동으로 실패 할 수도 있습니다 (권장하지 않음). 디자인의 특성에 따라 다릅니다.

대답

귀하의 질문에 대한 약간의 의견은 다음과 같습니다.

인터페이스의 구현이 아니라 자체 기능을 통해 객체의 기능을 식별해야합니다. 정적으로 강력하게 형식화 된 언어는 의도적으로 (설계 상) 이러한 가능성을 제한합니다.

추가:

객체 유형에 대한 분기는 악하다.

짓밟 기

c#태그를 추가하지 않았지만 일반적인 object-oriented상황 에서 묻습니다 .

당신이 설명하는 것은 정적 / 강력한 언어의 기술이며 "OO"에 대해서는 구체적이지 않습니다. 컴파일 타임에 변수 유형, 메소드 매개 변수 / 반환 값 정의 또는 명시 적 캐스트를 통해 충분히 좁은 유형이 없으면 해당 언어로 메소드를 호출 할 수 없다는 사실에서 문제점이 발생합니다. 과거에 이런 종류의 언어로 두 가지 변형을 모두 수행했으며 요즘에는 나에게 추한 것처럼 보입니다.

동적으로 유형이 지정된 OO 언어에서는 "오리진 입력"이라는 개념으로 인해이 문제가 발생하지 않습니다. 즉, 기본적으로 객체의 유형을 어디에서나 선언하지 않습니다 (생성 할 때 제외). 메시지를 객체로 보내면 객체가 해당 메시지를 처리합니다. 객체에 실제로 해당 이름의 메서드가 있는지 여부는 신경 쓰지 않습니다. 일부 언어에는 포괄적이고 포괄적 인 method_missing방법이있어 훨씬 더 유연합니다.

따라서 이러한 언어 (예 : Ruby)에서 코드는 다음과 같습니다.

account.reset_password

기간.

는 account하나, 암호를 재설정는 "거부"예외를 던져, 또는 " 'reset_password'을 처리하는 방법을 모른다"예외가 발생합니다.

어떤 이유로 든 명시 적으로 분기해야하는 경우 클래스가 아닌 기능에 대해 그렇게해야합니다.

account.reset_password  if account.can? :reset_password

( can?객체가 호출하지 않고 일부 메소드를 실행할 수 있는지 여부를 확인하는 메소드가 있습니다.)

내 개인 환경 설정은 현재 동적으로 유형이 지정된 언어이지만 개인 환경 설정일뿐입니다. 정적으로 유형이 지정된 언어에도 적용 할 수 있으므로이 유형을 정적으로 유형이 지정된 언어에 대한 배쉬로 사용하지 마십시오.

귀하의 선택은 다른 동기 부여 힘에서 비롯된 것 같습니다. 첫 번째는 열악한 객체 모델링으로 인해 해킹 된 것으로 보입니다. 그것은 당신의 추상화가 다형성을 깨뜨리기 때문에 틀렸다는 것을 보여주었습니다. 아마도 Open closed 원리를 깨뜨릴 수 있습니다.

두 번째 옵션은 OOP 관점에서 괜찮을 수 있지만 유형 캐스팅은 혼란 스럽습니다. 계정에서 비밀번호를 재설정 할 수 있다면 왜 유형 변환이 필요한가요? 귀하의 CanResetPassword조항이 계정 추상화의 일부인 기본적인 비즈니스 요구 사항을 나타내는 것으로 가정하면 두 번째 옵션은 좋습니다.