현재의 답변은 모두 부분적으로 만 히트 한 것으로 보이며 핵심 아이디어를 흐리게하는 예제에 중점을 둡니다. 이것은 (전적으로) OOP 원칙이 아니라 일반적으로 소프트웨어 설계 원칙입니다.

이 문구에서 “가변적”인 것은 코드입니다. 크리스토프는 것이 보통이라고 말하는 점에 있습니다 당신이 자주 변화, 예상 이. 목표는 코드의 향후 변경으로부터 자신을 보호하는 것입니다. 이것은 인터페이스에 대한 프로그래밍과 밀접한 관련이 있습니다 . 그러나 Christophe는이를 “구현 세부 사항”으로 제한하지 않습니다. 실제로이 조언의 가치는 종종 요구 사항의 변화로 인해 발생합니다 .

이것은 David Arno가 생각하는 캡슐화 상태와 간접적으로 만 관련이 있습니다. 이 조언이 항상 캡슐화 상태를 제안하는 것은 아니며 종종 불변의 객체에도 적용됩니다. 실제로 상수의 이름을 지정하는 것은 다양한 것을 캡슐화하는 (매우 기본적인) 형태입니다.

CandiedOrange는 “세부 사항”으로 “다양한 내용”을 명시 적으로 나타냅니다. 이것은 부분적으로 만 정확합니다. 나는 다양한 코드가 어떤 의미에서는 “세부 사항”이지만 “세부 사항”을 정의하지 않는 한 “세부 사항”은 변하지 않을 수 있다는 데 동의합니다. 다양하지 않은 세부 사항을 캡슐화해야하는 이유가있을 수 있지만이 내용은 하나가 아닙니다. 대략적으로, “dog”, “cat”및 “duck”이 처리해야 할 유일한 유형이라는 확신이 있다면 CandiedOrange가 리팩토링을 제안하지 않습니다.

다른 상황에서 CandiedOrange의 예제를 캐스팅하는 경우 C와 같은 절차 언어가 있다고 가정합니다.

if (pet.type() == dog) {
  pet.bark();
} else if (pet.type() == cat) {
  pet.meow();
} else if (pet.type() == duck) {
  pet.quack()
}

앞으로이 코드 조각이 변경 될 것이라고 합리적으로 기대할 수 있습니다. 새로운 프로 시저를 정의하여 간단히 “캡슐화”할 수 있습니다.

void speak(pet) {
  if (pet.type() == dog) {
    pet.bark();
  } else if (pet.type() == cat) {
    pet.meow();
  } else if (pet.type() == duck) {
    pet.quack()
  }
}

코드 블록 대신이 새로운 프로 시저를 사용합니다 (예 : “추출 방법”리팩토링). 이 시점에서 “cow”유형을 추가하거나 speak절차를 업데이트하기 만하면됩니다. 물론 OO 언어에서는 CandiedOrange의 답변에서 언급 한 것처럼 동적 디스패치를 ​​활용할 수 있습니다. pet인터페이스를 통해 액세스하면 자연스럽게 발생합니다 . 동적 디스패치를 ​​통해 조건부 논리를 제거하는 것은 내가이 절차 적 표현을 한 이유 중 하나 인 직교 관심사입니다. 또한 OOP에만 해당되는 기능이 필요하지 않다는 점을 강조하고 싶습니다. OO 언어에서도 다양한 내용을 캡슐화한다고해서 반드시 새로운 클래스 나 인터페이스를 만들어야하는 것은 아닙니다.

좀 더 OO에 가깝지 않은 좀 더 전형적인 예로써, 목록에서 중복을 제거하고 싶다고 가정 해보십시오. 다른 목록에서 지금까지 본 항목을 추적하고 본 항목을 제거하여 목록을 반복하여 구현한다고 가정 해 봅시다. 적어도 성능상의 이유로 보이는 항목을 추적하는 방법을 변경하려고 할 수 있다고 가정하는 것이 합리적입니다. 다양한 것을 캡슐화하는 규범은 보이는 항목 세트를 나타내는 추상 데이터 유형을 작성해야 함을 나타냅니다. 우리의 알고리즘은 이제이 추상 집합 데이터 형식에 대해 정의되며, 이진 검색 트리로 전환하기로 결정하면 알고리즘을 변경하거나 관리 할 필요가 없습니다. OO 언어에서는 클래스 또는 인터페이스를 사용하여이 추상 데이터 유형을 캡처 할 수 있습니다. SML / O ‘와 같은 언어로

요구 사항 중심의 예에서는 일부 비즈니스 논리와 관련하여 일부 필드의 유효성을 검사해야한다고 가정하십시오. 현재 특정 요구 사항이있을 수 있지만 요구 사항이 진화 할 것이라고 강력하게 의심합니다. 현재 로직을 자체 프로 시저 / 함수 / 규칙 / 클래스에 캡슐화 할 수 있습니다.

이것이 “다양한 것을 캡슐화하는”의 일부가 아닌 직교 관심사이지만, 현재 캡슐화 된 논리에 의해 매개 변수화되는 것은 당연하다. 이는 일반적으로보다 유연한 코드로 이어지고 캡슐화 된 논리를 수정하는 대신 대체 구현으로 대체하여 논리를 변경할 수 있습니다.

답변

class Course {
    public LinkedList<Student> Atendees;
    public bool register (Student s);
    ...
}