실제로 열린 원칙을 고수하는 방법

공개 원칙의 의도를 이해합니다. 수정하지 않고 확장하도록 지시함으로써 수정하는 동안 이미 작동하는 것을 깨뜨릴 위험을 줄입니다.

그러나이 원칙이 실제로 어떻게 적용되는지 이해하는 데 어려움이있었습니다. 내 이해에는 두 가지 방법이 있습니다. 변경 전과 후에 :

1. 이전 : 추상화에 프로그래밍하고 가능한 한 '미래를 예측'하십시오. 예를 들어, 향후 시스템에 s가 추가 drive(Car car)되면 방법 이 변경 Motorcycle되어 OCP를 위반할 수 있습니다. 그러나이 방법 drive(MotorVehicle vehicle)은 향후 변경 될 가능성이 적으므로 OCP를 준수합니다.

   그러나 미래를 예측하고 시스템에 어떤 변화가 있을지 미리 알기는 매우 어렵습니다.

2. 이후 : 변경이 필요한 경우 현재 코드를 수정하는 대신 클래스를 확장하십시오.

연습 # 1은 이해하기 어렵지 않습니다. 그러나 신청 방법을 이해하는 데 어려움이있는 것은 연습 # 2입니다.

예를 들어 (YouTube의 비디오에서 가져 왔습니다) : 클래스에 CreditCard객체 를 허용하는 메소드가 있다고 가정 해 봅시다 makePayment(CraditCard card). 하루 Voucher가 시스템에 추가됩니다. 이 방법은 지원하지 않으므로 수정해야합니다.

처음에 메소드를 구현할 때 미래와 프로그램을 더 추상적 인 용어로 예측하지 못했습니다 (예 : makePayment(Payment pay)이제 기존 코드를 변경해야 함).

실습 # 2는 수정하는 대신 확장하여 기능을 추가해야한다고 말합니다. 그게 무슨 뜻이야? 기존 코드를 단순히 변경하는 대신 기존 클래스를 서브 클래 싱해야합니까? 코드를 다시 쓰지 않기 위해 래퍼를 만들어야합니까?

또는 원칙은 '기능을 올바르게 수정 / 추가하는 방법'을 말하는 것이 아니라 '처음에 프로그램을 변경하지 않아도되는 방법 (예 : 추상화에서 추상화)'을 말하는가?

디자인 원칙은 항상 서로 균형을 이루어야합니다. 미래를 예측할 수 없으며 대부분의 프로그래머는 시도 할 때 끔찍하게 행동합니다. 그렇기 때문에 우리 는 주로 복제에 관한 것이지만 다른 디자인 원칙에 대한 리팩토링에도 적용되는 3 규칙을 사용합니다.

인터페이스를 하나만 구현 한 경우 확장이 수행 될 위치가 명확하지 않으면 OCP에 대해 신경 쓸 필요가 없습니다. 실제로, 이 상황에서 과도하게 설계하려고 할 때 명확성을 잃는 경우가 종종 있습니다. 한 번 확장 하면 가장 쉽고 명확한 방법 인 경우 OCP 친화적으로 만들기 위해 리팩터링 합니다. 세 번째 구현으로 확장 할 때는 조금 더 노력이 필요한 경우에도 OCP를 고려하여 리팩토링해야합니다.

실제로 두 개의 구현 만있는 경우 세 번째를 추가 할 때 리팩토링하는 것은 그리 어렵지 않습니다. 그 시점을지나 성장을 유지하게되면 귀찮게됩니다.

나는 당신이 미래를 너무 멀리보고 있다고 생각합니다. 현재의 문제를 유연하게 개방 / 폐쇄하는 방식으로 해결하십시오.

drive(Car car)메소드 를 구현해야한다고 가정 해 봅시다 . 언어에 따라 몇 가지 옵션이 있습니다.

• 오버로딩 (C ++)을 지원하는 언어의 경우 drive(const Car& car)

  언젠가는을 (를) 필요 drive(const Motorcycle& motorcycle)로하지만을 (를) 방해하지 않습니다 drive(const Car& car). 문제 없어요!

• 오버로드를 지원하지 않는 언어 (Objective C)의 경우 메소드에 유형 이름을 포함하십시오 -driveCar:(Car *)car.

  어느 시점에서 당신은 필요할지 -driveMotorcycle:(Motorcycle *)motorcycle모르지만 다시는 방해하지 않을 것입니다.

이를 통해 drive(Car car)수정 이 가능 하지만 다른 차량 유형으로 확장 할 수 있습니다. 이 미니멀리스트 미래 계획을 통해 오늘 작업을 수행 할 수 있지만 미래에 자신을 차단할 수는 없습니다.

필요한 가장 기본적인 유형을 상상하려고하면 무한 회귀로 이어질 수 있습니다. Segue, 자전거 또는 점보 제트기를 운전하고 싶을 때 일어나는 일. 사람들이 이동성을 위해 사용하고 사용하는 모든 장치를 설명 할 수있는 단일 일반 추상 유형을 어떻게 구성합니까?

공개 원칙의 의도를 이해합니다. 수정하지 않고 확장하도록 지시함으로써 수정하는 동안 이미 작동하는 것을 깨뜨릴 위험을 줄입니다.

또한 기존 객체의 동작을 변경하지 않음으로써 해당 방법에 의존하는 모든 객체를 손상시키지 않습니다. 개체가 동작 변경을 알리면 다른 개체가 해당 동작을 기대하는 것을 정확히 알지 못하고 알려진 동작 및 예상 동작을 변경하므로 위험합니다.

그게 무슨 뜻이야? 기존 코드를 단순히 변경하는 대신 기존 클래스를 서브 클래 싱해야합니까?

예.

"신용 카드 만 허용"은 공용 인터페이스를 통해 해당 클래스의 동작의 일부로 정의됩니다. 프로그래머는이 객체의 메서드는 신용 카드 만 사용한다고 세상에 선언했습니다. 그녀는 특히 명확한 방법 이름을 사용하지 않았지만 그 방법을 사용했습니다. 나머지 시스템은 이것에 의존합니다.

당시에는 의미가 있었지만 지금 변경해야 할 경우 신용 카드 이외의 것을 허용하는 새로운 클래스를 만들어야합니다.

새로운 행동 = 새로운 클래스

제쳐두고 -미래를 예측하는 좋은 방법은 당신이 방법을 지정한 이름에 대해 생각하는 것입니다. 메소드에 특정 규칙이있는 메소드에 makePayment와 같은 일반적인 일반적인 메소드 이름을 지정하여 정확히 어떤 지불을 할 수 있습니까? 그것은 코드 냄새입니다. 특정 규칙이있는 경우 메소드 이름에서이를 명확하게해야합니다. makePayment는 makeCreditCardPayment 여야합니다. 객체를 처음 작성할 때이 작업을 수행하면 다른 프로그래머가이 객체에 대해 감사하게됩니다.