실제 값을 나타내는 상수를 업데이트하는 것이 공개 폐쇄 원칙을 위반합니까?

근로자의 연간 순소득을 계산하는 수업이 있습니다. 세금 비율을 나타내는 상수가 있습니다. 그러나 어느 날 세율이 변경되었으므로 코드를 수정해야합니다.

이 상수를 수정하는 행위 는 클래스가 수정을 위해 폐쇄되어야한다고 가정하기 때문에 공개 폐쇄 원칙 위반을 나타 냅 니까?

사용자 B, C 및 D의 사용을 위해 어떤 종류의 블랙 박스 라이브러리에서 공급 업체 A가 제공하는 클래스 또는 구성 요소를 생각할 때 OCP를 더 잘 이해할 수 있습니다 (이는 명확성을 위해 사용하는 정신적 모델입니다. 실제로 클래스의 유일한 사용자가 A 자신인지 여부는 중요하지 않습니다.

라이브러리 소스 코드를 수정할 필요없이 B, C 및 D가 제공된 클래스를 다른 사용 사례에 사용하거나 재사용 할 수있는 경우 구성 요소는 OCP를 충족합니다 ( 사용 사례 범주와 관련하여 ). 이것을 달성하는 다른 방법이 있습니다.

• 클래스를 상속 가능하게 만들기 (일반적으로 템플릿 메소드 패턴 또는 전략 패턴과 함께)

• 의존성 주입을위한 "주 입점"제공

• 클래스 또는 구성 요소에 대한 구성 매개 변수를 제공하여 (예 : 생성자 매개 변수 "tax percent"를 사용하거나 다른 구성 메커니즘을 사용하여)

• 프로그래밍 언어 또는 생태계에 따라 다른 수단

교과서에서 발견되는 전형적인 예는 종종 첫 번째 또는 두 번째 유형입니다 (이 책의 저자의 눈에는 세 번째 유형이 언급하기에 너무 사소하기 때문에).

보시다시피, 이것은 공급 업체 A 가 소스 코드 를 변경하는 것을 금지하는 것과 아무런 관련이 없습니다 (버그 수정, 최적화 또는 이전 버전과 호환되는 방식으로 새 기능 추가 등). 이는 OCP와 관련이 없습니다. OCP는 A가 lib에서 구성 요소의 인터페이스와 세분성을 설계하는 방법에 관한 것이므로 다른 재사용 시나리오 (세율이 다른 재개와 같은)가 변경 요구 사항을 자동으로 유도하지는 않습니다.

따라서 다른 사람들이 여기에서 말한 내용에도 불구하고 그 대답은 분명히 "예" 입니다. OCP를 위반하는 것입니다.

편집 : 누군가 가이 주제에 대한 자세한 블로그 게시물을 쓴 것 같습니다 . Derek Elkins가 지적한 것처럼 그 일부를 더 잘 표현할 수 있었지만 저자는 일반적으로 "OCP 이행"이 절대적인 속성이 아니라 특정 상황에서만 평가할 수있는 것으로 생각합니다. 요구 사항 변경 범주

다른 사람들이 말했듯이, 이상적으로 노동자 소득 계급은 상수의 매개 변수화를 허용 하여이 계급을 그 가치와 독립적으로 만듭니다.

궁극적으로 호출 응용 프로그램은 외부 구성 (예 : 파일) 측면에서 매개 변수화를 허용 할 수도 있습니다. 외부 구성을 설정 한 후에는 세율을 변경할 수 있습니다. 시작시 구성 파일을 한 번만 읽은 경우 업데이트 된 세율을 적용하려면 응용 프로그램을 다시 시작해야하므로 고려해야합니다. 마음. 우리는 지시가있을 때 구성을 다시 읽는 응용 프로그램 기능을 제공하거나 구성 파일이 변경 될 때 알 수있는보다 복잡한 메커니즘을 제공 할 수 있습니다 ...

장기적으로 세금 문제는 단지 몇 퍼센트 이상을 요구할 수 있습니다. 예를 들어 언젠가는 세금 법이 더 복잡하고 몇 퍼센트와 일부 상수가 필요합니다 (예 : X %에서 세금이 10 만 달러 미만인 경우). 나머지는 Y %로 과세됩니다.

이것은 기본적으로 전략 패턴 사용을 제안합니다. 여기서 주요 클래스는 세금 계산을위한 전략 객체를 받아들입니다.

구성 파일에서 다양한 전략 (및 % 및 $ 상수)을 선택할 수 있어야합니다. 이제 새로운 전략을 추가하려면 새로운 코드를 추가해야하지만 기존 코드를 반드시 업데이트 할 필요는 없습니다.

각 전략은 실제 세금 계산 방법과 함께 자체 외부 구성 인수를 구문 분석 / 해석하는 방법을 알고 있습니다.

역동적으로 세금은 해당 지역에 따라 달라질 수 있으므로 수입 또는 직원 (또는 둘 다)과 관련된 지역이있을 수 있습니다. 외부 구성에서는 로캘을 세금 전략과 연결할 수 있습니다.

또한 이러한 것들을 명시 적으로 관리하는 의존성 주입을 참조하십시오 .

세금 값을 변경하기 위해 클래스를 수정해야하는 경우 실제로 해당 디자인이 OCP를 위반하는 것입니다. 지금까지 설명한 내용에 적합한 디자인은 계산기 클래스가 세금 값을 매개 변수로 사용하는 것입니다.

클래스가 인스턴스화 된 경우 (정적 클래스가 아님) 생성자에 값이 주입되는 세금 변수 클래스 속성을 만들어 클래스 응집력을 향상시킵니다.

요컨대, 현재 디자인은 클래스가 실제로 상수가 아닌 상수 값에 의존하게합니다 (PI의 값과 같이 아무 것도 변하지 않는 값으로 상수 정의). OCP를 위반합니다. 세금 값을 생성자 인수로 받도록 디자인을 변경하십시오.

@Becuzz에 전적으로 동의하고 이것을 요약하고 싶습니다. OCP는 클래스에 주입 된 재사용 된 (따라서 유용한) 추상화를 찾는 것입니다. 따라서 클래스의 동작은 코드를 변경하는 것이 아니라 다른 구현을 제공하여 수정됩니다. 이것은 Robert Martin의 저서 " Agile Software Development, Principles, Patterns, and Practices " 에서 명확하게 밝혀졌으며 해당 장의 "개방형 원칙", "추상이 핵심"하위 장을 확인하십시오. 상속을 통해서만 행동을 수정할 수 있다는 또 다른 오해를 분명히한다. 1988 년 Robert Martin이 아니라 " Object Oriented Software Construction " 이라는 책에서 제안한 것은 Bertrand Meyer였습니다 .

내가 보는 방식은 공개 폐쇄 원칙을 위반하는 것이 아닙니다. 그러나 시간에 변화가있는 것 (예 : 세금 비율)이 상수라는 사실은 설계상의 결함입니다. 상수 값을 변경하지 말고 세금 비율을 처리하는 방법을 변경해야합니다. 이것은 전체를 다시 컴파일하지 않고 수정할 수있는 일종의 설정이어야합니다.