“Child x = new Child ();”대신“Parent x = new Child ();”가 후자를 사용할 수 있다면 나쁜 습관입니까?

예를 들어, 다음과 같은 조각을 만드는 코드를 보았습니다.

Fragment myFragment=new MyFragment();

MyFragment 대신 변수를 Fragment로 선언합니다. MyFragment는 Fragment의 자식 클래스입니다. 이 코드는 다음과 같아야한다고 생각하기 때문에이 코드 줄을 만족시키지 못했습니다.

MyFragment myFragment=new MyFragment();

어느 것이 더 구체적입니까?

또는 질문의 일반화에서 사용하는 것이 나쁜 습관입니까?

Parent x=new Child();

대신에

Child x=new Child();

컴파일 오류없이 전자를 후자로 바꿀 수 있다면?

상황에 따라 다르지만 가능한 가장 추상적 인 유형을 선언해야한다고 주장 합니다. 그렇게하면 코드가 가능한 한 일반적이며 관련이없는 세부 사항에 의존하지 않습니다.

예는를 갖는 것 LinkedList및 ArrayList이로부터 양쪽이 하강 List. 코드가 어떤 종류의 목록에서도 똑같이 잘 작동한다면 임의의 하위 클래스 중 하나로 코드를 제한 할 이유가 없습니다.

JacquesB의 대답은 약간 추상적이지만 정확합니다. 몇 가지 측면을 더 명확하게 강조하겠습니다.

코드 스 니펫에서 new키워드 를 명시 적으로 사용하고 구체적 유형에 따라 추가 초기화 단계를 계속하고 싶을 때 해당 구체적인 유형으로 변수를 선언해야합니다.

예를 들어 다른 곳에서 해당 항목을 가져 오면 상황이 다릅니다 IFragment fragment = SomeFactory.GiveMeFragments(...);. 여기서 팩토리는 일반적으로 가능한 가장 추상적 인 유형을 반환해야하며 하향 코드는 구현 세부 사항에 의존해서는 안됩니다.

잠재적으로 성능 차이가 있습니다.

파생 클래스가 봉인 된 경우 컴파일러는 가상 호출을 인라인하고 최적화하거나 제거 할 수 있습니다. 따라서 상당한 성능 차이가있을 수 있습니다.

예 : ToString가상 통화이지만 String봉인되어 있습니다. 에 String, ToString당신이 선언 그렇다면, 아무 조합입니다 object즉 가상 전화의 당신이 선언하는 경우, String클래스가 봉인되어 있기 때문에 컴파일러가 알고있는 어떤 파생 클래스 메소드를 오버라이드 (override) 한 즉 아무 조합 없습니다 그래서. ArrayListvs에 유사한 고려 사항이 적용됩니다 LinkedList.

따라서 객체의 구체적인 유형을 알고 있고 숨길 캡슐화 이유가없는 경우 해당 유형으로 선언해야합니다. 방금 객체를 만들었으므로 콘크리트 유형을 알고 있습니다.

중요한 차이점은 필요한 액세스 수준입니다. 그리고 추상화에 대한 모든 좋은 대답은 동물과 관련이 있습니다.

- 우리는 당신이 몇 가지 동물을 가정하자 Cat Bird및 Dog. 이제,이 동물은 몇 가지 일반적인 행동이 - move(), eat()하고 speak(). 그들은 모두 다르게 먹고 다르게 말하지만, 동물이 먹거나 말해야한다면 어떻게하는지 신경 쓰지 않습니다.

그러나 때때로 나는한다. 난 가드캣이나 가드 버드를 세게 한 적이 없지만 가드 독이있다. 누군가가 내 집에 침입했을 때, 나는 침입자를 놀라게하기 위해 말을 할 수 없습니다. 나는 짖을 개가 정말로 필요하다. 이것은 그의 말과는 다르다.

따라서 침입자가 필요한 코드에서는 실제로해야합니다. Dog fido = getDog(); fido.barkMenancingly();

그러나 대부분의 경우, 동물이 간식을 먹기 위해 야옹이나 짹짹을 할 수있는 트릭을 기뻐할 수 있습니다. Animal pet = getAnimal(); pet.speak();

그래서 더 구체적으로, ArrayList를이 가지고 몇 가지 방법 List하지 않습니다. 특히 trimToSize(). 현재 99 %의 사례에서는이 점에 신경 쓰지 않습니다. 는 List우리가 걱정하는 거의 결코 큰 충분하다. 그러나 때가 있습니다. 따라서 때때로 ArrayList실행을 요청 trimToSize()하고 백업 배열을 더 작게 만들어야합니다.

이것은 시공시에 이루어질 필요는 없습니다. 절대적으로 확실하다면 반환 방법이나 캐스트를 통해 수행 할 수 있습니다.

일반적으로 말해서

var x = new Child(); // C#

또는

auto x = new Child(); // C++

변수가 초기화 된 것과 다른 유형을 갖는 적절한 이유가없는 한 로컬 변수의 경우.

(여기서는 C ++ 코드가 스마트 포인터를 사용해야한다는 사실을 무시하고 있습니다. 실제로 알 수없는 두 줄 이상이 있거나없는 경우가 있습니다.)

여기서 일반적인 아이디어는 변수의 자동 유형 감지를 지원하는 언어를 사용하여 코드를 더 쉽게 읽고 올바른 작업을 수행하는 것입니다 (즉, 컴파일러의 유형 시스템은 최대한 최적화하고 초기화를 새로운 것으로 변경 함) 대부분의 초록이 사용 된 경우에도 형식이 작동합니다).

이 코드는 이해하기 쉽고 수정하기 쉽기 때문에 좋습니다.

var x = new Child(); 
x.DoSomething();

의도를 전달하기 때문에 좋습니다.

Parent x = new Child(); 
x.DoSomething(); 

일반적이고 이해하기 쉽기 때문에 좋습니다.

Child x = new Child(); 
x.DoSomething(); 

정말 나쁜 방법 중 하나 는 방법이있는 Parent경우에만 사용 Child하는 것 DoSomething()입니다. 의도를 잘못 전달하기 때문에 좋지 않습니다.

Parent x = new Child(); 
(x as Child).DoSomething(); // DON'T DO THIS! IF YOU WANT x AS CHILD, STORE x AS CHILD

이제 질문이 구체적으로 요구하는 경우에 대해 좀 더 자세히 설명하겠습니다.

Parent x = new Child(); 
x.DoSomething(); 

후반을 함수 호출로 만들어서 다르게 형식화 해 봅시다 :

WhichType x = new Child(); 
FunctionCall(x);

void FunctionCall(WhichType x)
    x.DoSomething(); 

이것은 다음과 같이 단축 될 수 있습니다.

FunctionCall(new Child());

void FunctionCall(WhichType x)
    x.DoSomething();

여기서는 WhichType성능 문제가없는 한 함수가 작동 할 수있는 가장 기본 적이고 추상적 인 유형이어야한다는 것이 널리 받아 들여지고 있다고 가정합니다 . 이 경우 적절한 유형은 Parent이거나 무언가 Parent에서 파생됩니다.

이 추론은 왜 유형을 사용 Parent하는 것이 좋은 선택 인지 설명 하지만 날씨가 좋지 않아 다른 선택은 나쁘다 (그렇지 않다).

TL; DR - 사용Child오버Parent지역 범위가 바람직하다. 가독성을 높이는 데 도움이 될뿐만 아니라 오버로드 된 분석법 해결이 제대로 작동하고 효율적인 컴파일이 가능하도록해야합니다.

로컬 범위에서

Parent obj = new Child();  // Works
Child  obj = new Child();  // Better
var    obj = new Child();  // Best

개념적으로 가능한 가장 많은 유형 정보를 유지하는 것입니다. 로 다운 그레이드하면 Parent기본적으로 유용 할 수있는 유형 정보를 제거합니다.

완전한 유형 정보를 유지하면 다음과 같은 네 가지 주요 이점이 있습니다.

1. 컴파일러에 자세한 정보를 제공합니다.
2. 독자에게 더 많은 정보를 제공합니다.
3. 보다 깨끗하고 표준화 된 코드.
4. 프로그램 논리를 더 변경 가능하게 만듭니다.

장점 1 : 컴파일러에 대한 추가 정보

명백한 유형은 오버로드 된 분석법 해결 및 최적화에 사용됩니다.

예 : 과부하 된 분석법 해결

main()
{
    Parent parent = new Child();
    foo(parent);

    Child  child  = new Child();
    foo(child);
}
foo(Parent arg) { /* ... */ }  // More general
foo(Child  arg) { /* ... */ }  // Case-specific optimizations

위의 예제에서 두 foo()호출 은 모두 작동 하지만 어떤 경우에는 오버로드 된 메소드 분석이 더 좋습니다.

예 : 컴파일러 최적화

main()
{
    Parent parent = new Child();
    var x = parent.Foo();

    Child  child  = new Child();
    var y = child .Foo();
}
class Parent
{
    virtual         int Foo() { return 1; }
}
class Child : Parent
{
    sealed override int Foo() { return 2; }
}

위의 예제에서 두 .Foo()호출은 결국 override을 반환 하는 동일한 메소드를 호출 합니다 2. 첫 번째 경우에는 올바른 방법을 찾기위한 가상 방법 검색이 있습니다. 이 가상 메소드 조회는 해당 메소드 이후의 두 번째 경우에는 필요하지 않습니다 sealed.

그의 대답에 비슷한 예를 제공 한 @Ben에게 감사의 말을 전한다 .

장점 2 : 독자에게 더 많은 정보

정확한 유형을 알고 Child있으면 (예 :) 코드를 읽는 사람에게 더 많은 정보를 제공하여 프로그램이 수행하는 작업을 쉽게 확인할 수 있습니다.

물론, 어쩌면 모두 이후 실제 코드에 중요하지 않습니다 parent.Foo();및 child.Foo();메이크업 감각, 그러나 처음으로 코드를 보는 사람, 자세한 내용은 그냥 일반 도움이됩니다.

또한, 개발 환경에 따라 IDE에 대한 추가 도움이 툴팁 및 메타 데이터를 제공 할 수 있습니다 Child보다 Parent.

장점 3 :보다 깨끗하고 표준화 된 코드

최근에 보았던 C # 코드 예제의 대부분 var은 기본적으로 축약 형입니다 Child.

Parent obj = new Child();  // Sub-optimal
Child  obj = new Child();  // Optimal, but anti-pattern syntax
var    obj = new Child();  // Optimal, clean, patterned syntax "everyone" uses now

var선언 이 아닌 진술을 보는 것은 단지 외모입니다. 상황에 맞는 이유가 있다면 대단하지만 그렇지 않으면 반 패턴으로 보입니다.

// Clean:
var foo1 = new Person();
var foo2 = new Job();
var foo3 = new Residence();

// Staggered:
Person foo1 = new Person();
Job foo2 = new Job();
Residence foo3 = new Residence();   

장점 4 : 프로토 타이핑을위한 더 가변적 인 프로그램 로직

처음 세 가지 장점은 큰 장점이었습니다. 이것은 훨씬 더 상황이 좋지 않습니다.

아직도, 다른 사람들이 Excel을 사용하는 것처럼 코드를 사용하는 사람들을 위해 우리는 끊임없이 코드를 변경하고 있습니다. 이 버전의 코드 Child에서 고유 한 메소드를 호출 할 필요는 없지만 나중에 코드의 용도를 변경하거나 재 작업 할 수 있습니다.

강력한 유형 시스템의 장점은 프로그램 논리에 대한 특정 메타 데이터를 제공하여 가능성을보다 쉽게 ​​알 수 있다는 것입니다. 이것은 프로토 타이핑에 매우 유용하므로 가능하면 유지하는 것이 가장 좋습니다.

개요

사용 Parent과부하 방법 해상도 엉망을 일부 컴파일러 최적화 억제 리더의 정보를 제거하고 코드 못 생겼다고한다.

사용하는 var것은 실제로 갈 길입니다. 빠르고 깨끗하며 패턴 화되어 있으며 컴파일러와 IDE가 작업을 올바르게 수행하도록 도와줍니다.

중요 :이 답변에 관한Parent대Child방법의 로컬 범위이다. Parentvs.의 문제는Child반환 유형, 인수 및 클래스 필드에서 매우 다릅니다.

주어진 parentType foo = new childType1();코드는 부모 유형 메소드를 사용하는 것으로 제한 foo되지만의 인스턴스뿐만 아니라 foo유형에서 파생되는 모든 객체 에 대한 참조에 저장할 수 있습니다 . 새로운 인스턴스가 참조를 보유 할 유일한 것이라면, 타입을로 선언하는 것이 좋습니다 . 반면 에 다른 유형에 대한 참조를 보유해야하는 경우 이를 가능하게 선언했습니다 .parentchildType1childType1foofoochildType1fooparentType

나는 사용하는 것이 좋습니다

Child x = new Child();

대신에

Parent x = new Child();

전자는 정보를 잃지 만 전자는 정보를 잃습니다.

전자는 후자로는 할 수 있지만 그 반대는 할 수없는 모든 것을 할 수 있습니다.

포인터를 더 자세히 설명하기 위해 여러 수준의 상속을하자.

Base-> DerivedL1->DerivedL2

그리고 new DerivedL2()변수 의 결과를 초기화하려고 합니다. 기본 유형을 사용하는 것은 당신에게 사용할 수있는 옵션 잎 Base또는 DerivedL1.

당신이 사용할 수있는

Base x = new DerivedL2();

또는

DerivedL1 x = new DerivedL2();

나는 다른 것을 선호하는 논리적 인 방법을 보지 못했습니다.

당신이 사용하는 경우

DerivedL2 x = new DerivedL2();

논쟁 할 것이 없습니다.

항상 변수를 가장 구체적인 유형으로 반환하거나 저장하지만 매개 변수를 가장 넓은 유형으로 허용하는 것이 좋습니다.

예 :

<K, V> LinkedHashMap<K, V> keyValuePairsToMap(List<K> keys, List<V> values) {
   //...
}

매개 변수는 List<T>매우 일반적인 유형입니다. ArrayList<T>, LinkedList<T>등은 모두이 방법에 의해 허용 될 수있다.

중요한 것은 반환 유형이 LinkedHashMap<K, V>아니라 Map<K, V>입니다. 누군가이 방법의 결과를에 할당하고 싶다면 Map<K, V>그렇게 할 수 있습니다. 이 결과는 단순한지도가 아니라 순서가 정의 된지도라는 것을 분명히 알려줍니다.

이 메소드가 돌려 주었을 경우 Map<K, V>. 호출자가를 원한다면 LinkedHashMap<K, V>유형 검사, 캐스트 및 오류 처리를 수행해야하는데 이는 실제로 성가시다.