클래스 또는 추상 클래스에서 상속

Question

일반적인 기능을 위해 기본 클래스에서 상속하는 여러 클래스가있는 경우 클래스 또는 추상 클래스를 사용하여 기본 클래스를 구현해야합니까?

Answer 1

기본 클래스를 인스턴스화 할 수 없으면 추상화합니다. 그렇지 않으면 정상적인 클래스로 두십시오.

Answer 2

기본 클래스를 단독으로 호출 할 계획이 없다면 추상 클래스로 정의해야합니다.

Answer 3

기본 클래스를 자체적으로 구현할지 여부에 따라 다릅니다.

추상 클래스는 개체를 만들 수 없습니다.

Answer 4

다릅니다. 문제의 기본 클래스가 파생되지 않고 자체에 존재하는 것이 맞습니까? 대답이 예이면 정규 클래스 여야하고 그렇지 않으면 추상 클래스 여야합니다.

Answer 5

기본 클래스를 인스턴스화하지 않아야하는 경우이를 추상 클래스로 지정해야합니다. 기본 클래스를 인스턴스화해야하는 경우 추상화하지 않아야합니다.

이

abstract class WritingImplement 
{ 
    public abstract void Write(); 
} 

class Pencil : WritingImplement 
{ 
    public override void Write() { } 
} 

그러나이 다음 예제에서 당신은 기본 클래스는 구체적인 의미를 가지고하는 방법을 볼 수는 기본 클래스가 어떤 구체적인 의미를 가지고 있지 않는 한 기본 클래스는 추상적 있도록하는 것이 합리적이 예에서

:

class Dog 
{ 
    public virtual void Bark() { } 
} 

class GoldenRetriever : Dog 
{ 
    public override void Bark() { } 
} 

정말 모든 꽤 주관적이다 - 당신은 당신의 특정 도메인의 필요에 따라 꽤 좋은 판단 통화를 할 수 있도록해야한다.

Answer 6

추상 클래스는 미리 정의 된 기능에 매우 적합합니다. 예를 들어 클래스가 노출해야하는 최소 정확한 동작을 알고 있지만이를 수행하는 데 사용해야하는 데이터 나 정확한 구현을 알 수없는 경우입니다.

abstract class ADataAccess 
{ 
    abstract public void Save(); 
} 

일반 (비 추상) 클래스는 비슷한 항목에 유용 할 수 있지만 구현 세부 사항을 작성해야 해당 항목을 작성할 수 있습니다.

public class DataAccess 
{ 
    public void Save() 
    { 
     if (_is_new) 
     { 
      Insert(); 
     } 
     else if (_is_modified) 
     { 
      Update(); 
     } 
    } 
} 

또한, 프로토 타입 정의의 같은 종류를 정의하기 위해 (개별적으로 또는 클래스에 대한 추상적 여부) 인터페이스를 사용할 수 있습니다.

interface ISaveable 
{ 
    void Save(); 
    void Insert(); 
    void Update(); 
} 

class UserAccount : ISavable 
{ 
    void ISavable.Save() { ... } 
    void ISavable.Insert() { ... } 
    void ISavable.Update() { ... } 
} 

또 다른 옵션을 사용할 수 제네릭

class GenDataAccess<T> 
{ 
    public void Save() 
    { 
     ... 
    } 
} 

이러한 모든 방법

클래스가 함께 작동하는 특정 프로토 타입을 정의 할 수 있습니다. 코드 A가 코드 B와 통신 할 수 있도록하는 방법. 물론 위의 모든 것을 원하는대로 조합하여 사용할 수 있습니다. 확실한 올바른 방법은 없지만 인터페이스 및 추상 클래스를 정의한 다음 인터페이스를 참조하는 것이 좋습니다. 이 방법을 사용하면 상위 수준의 클래스에서 "배관 작업"에 대한 사고 요구 사항을 없애고 최대한의 유연성을 유지할 수 있습니다. (인터페이스가 추상 기본 클래스를 사용하는 요구 사항을 제거하지만 옵션으로 남겨 둡니다).

Answer 7

추상 클래스는 부분적으로 구현 된 클래스입니다.

그 자체로 추상 클래스의 인스턴스를 갖는 것이 타당하지 않으므로 파생되어야합니다. 기본 클래스를 만들려면 추상 클래스가 될 수 없습니다.

저는 추상 클래스를 모든 하위 클래스에 공통적 인 일부 멤버가 미리 정의 된 인터페이스로 생각하고 있습니다. 이것의

Answer 8

생각해 다른 방법

내 기본 클래스는 그 자체의 완전한 객체인가?

대답이 '아니오'라면 추상화하십시오. 그것이 그렇다면 당신은 그것을 구체적인 클래스로 만들고 싶을 것입니다.

Answer 9

내가 제안 :

• 가 인터페이스를 확인합니다.
• 기본 클래스에 인터페이스를 구현하십시오.
• 기본 클래스를 추상 클래스가 아닌 실제 클래스로 만듭니다 (아래 이유 참조).

내가 대신 추상 클래스의 실제 수업을 선호하는 이유는 추상 클래스는 향후 옵션을 불필요하게을 제한하는 인스턴스화 할 수 없다는 것입니다. 예를 들어, 나중에 기본 클래스에서 제공하는 상태와 메서드가 필요할 수 있지만 인터페이스를 구현할 필요가 없으며 인터페이스를 구현할 필요가 없습니다. 기본 클래스가 추상적 인 경우 기본 클래스가 일반 클래스 인 경우 기본 클래스의 인스턴스를 만들어 다른 클래스의 구성 요소로 유지하고 인스턴스를 위임하여 인스턴스를 다시 사용할 수 있습니다. 상태/방법 제공.

예. 자주 발생하지 않지만 요점은 다음과 같습니다. 기본 클래스를 추상화하면 이유가 없을 때 이런 종류의 재사용/솔루션을 방지 할 수 있습니다. 기본 클래스를 인스턴스화하는 것은 어떻게 든 위험 할 경우 지금

, 그때는 추상적 만들 - 바람직 경우, 덜 위험하게 은행 계좌와 같은 그것의 수 ;-)

Answer 10

생각한다

당신 "계정"이라는 일반 추상 기본 계정을 만들 수 있습니다. 이는 고객 세부 정보와 같은 기본 정보를 보유합니다.

"SavingAccount"또는 "DebitAccount"라는 2 개의 파생 클래스를 만들 수 있습니다.이 클래스는 기본 클래스 동작의 이점을 누리는 동시에 고유 한 특정 동작을 수행 할 수 있습니다.

이것은 고객이 저축 예금 계좌 또는 계좌 이체가 있어야하는 상황입니다. 실제 계정에서는 설명이없는 계좌 만있는 것은 아니기 때문에 일반적인 '계좌'는 허용되지 않습니다.

필요에 따라 유사한 시나리오를 만들 수 있으면 추상화가 필요합니다.

Answer 11

많은 OI 수업을 다시해야한다고 생각합니다.

OOA/OOD의 기본 기본 원리는 더 이상 추상화 할 수 없을 때까지 추상적 인 추상을 추상화하는 것입니다. 만약 당신이 바라 보는 것이 추상적 인 것이라면 당신의 OOA/OOD가 이미 말했던 것입니다.그러나 "코드"가 추상적인지 아닌지 궁금하다면 단어가 의미하는 것이 무엇인지 모르고 다시 기본 OOA/OOD/OOP를 배워야합니다 :-)

디자인 패턴 및 고조파 이론을 배우면 대폭적으로 OO 디자인에 도움이됩니다!