"안녕하세요, 아미고! OOP의 또 다른 이점에 대해 말씀드리고 싶습니다. 프로그램은 건물보다 동물에 더 가깝습니다. 프로그램은 지어지는 것이 아니라 성장하는 것입니다. 개발 은 끊임없는 변화를 의미합니다. 건설에서는 다음을 수행할 수 있습니다. 좋은 계획을 세우고 그것을 T까지 따르십시오. 하지만 소프트웨어 개발에서는 그렇지 않습니다."
종종 의도한 대로 작업을 수행할 수 없으며 프로그램을 많이 재작업해야 합니다. 그리고 더 자주 고객의 요구 사항이 변경됩니다.
"하지만 고객이 정말 자세한 사양을 제공하면 어떻게 될까요?"
" 시간 경과에 따라 어떤 일이 발생하는지 살펴보십시오. 제품이 성공하면 고객은 새 버전을 출시하고 싶어할 것 입니다 . 따라서 소프트웨어 개발은 변화의 연속입니다. 주기만 다릅니다. 매주, 한 달에 한 번 또는 6개월마다 새 버전이 출시될 수 있습니다."
"그래서 우리는 이 모든 것으로부터 어떤 결론을 내립니까?"
"제품의 내부 구조는 최소한의 재작업으로 주요(및 경미한) 변경을 허용하는 방식으로 유지되어야 합니다."
"어떻게 합니까?"
"우리는 프로그램이 서로 상호 작용하는 개체로 구성되는 방법에 대해 이미 이야기했습니다. 두꺼운 점을 사용하여 보드의 모든 프로그램 개체를 나타냅니다. 각 개체(점)에서 모든 개체로 화살표를 그릴 것입니다. (점)과 상호 작용합니다."
이제 개체(도트)를 그룹으로 결합해 보겠습니다. 점들은 다른 점들보다 서로 더 많이 연결되어 있으면 같은 그룹에 속합니다. 대부분의 점 화살표가 해당 그룹의 점을 가리키면 개체를 올바르게 그룹화한 것입니다. 같은 그룹 내의 도트는 단단히 결합되어 있는 반면, 다른 그룹의 도트는 느슨하게 결합되어 있다고 합니다.
이것을 « 느슨한 결합의 원리 » 라고 합니다 . 프로그램은 여러 부분, 종종 계층으로 나뉘며, 논리는 내부 구조에 강하게 연결되고 다른 계층/부분에는 약하게 연결됩니다. 계층 간의 상호 작용은 일반적으로 고도로 구획화되어 있습니다. 한 계층은 해당 클래스의 작은 하위 집합만 사용하여 다른 계층을 호출할 수 있습니다.
"동일한 '분업' 원칙이지만 더 큰 규모로?"
"정확합니다. 이를 통해 부서를 개편하고 효율성을 높이고 더 많은 사람을 고용할 수 있습니다. 부서 간 프로토콜을 변경하지 않으면 모든 변경 사항이 로컬에 적용됩니다. 아무도 재교육을 받을 필요가 없습니다. 전체 시스템을 재작업해야 합니다. 각 부서는 부서 간 상호 작용 메커니즘을 잘 선택하면 이러한 방식으로 내부 업무를 최적화할 수 있습니다."
"잘 선택되면. 잘 선택되지 않으면?"
'그러면 변경을 위한 « 흔드는 공간 »이 금방 바닥나고 전체 시스템을 재작업해야 합니다. 그것은 때때로 발생합니다. 미래를 예측할 수는 없지만 프로그램을 다시 작성해야 하는 횟수를 최소화할 수 있습니다."
"알았어. 프로그램을 그렇게 나누는 것이 이득인 것 같은데, OOP는 어떻게 나오는 거지?"
"부서를 구성하는 방법과 상호 작용 방식을 선택할 때 ' 추상화 원칙 '을 적용합니다. 프로그래밍에서 추상화는 프로그램을 분할하는 가장 좋은 방법과 각 부분이 상호 작용하는 방식을 결정하는 데 사용됩니다. 이 원칙은 다음을 수행할 수 있습니다. 또한 프로그램을 개별 클래스로 나눌 때까지 구성 부분에 반복적으로 적용됩니다."
"그리고 이러한 부품의 내부 구조를 숨기고 다른 부품과 상호 작용하는 방식을 엄격하게 제한하는 것이 캡슐화입니다 . 맞습니까?"
"정확합니다. 캡슐화와 추상화는 OOP의 초석입니다. 좋은 프로그램은 이 두 원칙을 준수해야 합니다. 나중에 다른 원칙을 살펴보고 그 장점을 이해하게 될 것입니다."
"좋은 물건이야. 기다릴 수 없어!"
GO TO FULL VERSION