OOP가 필요한 이유는 무엇입니까?

1. 회사 연혁

저는 OOP가 대규모 시스템의 복잡성과 싸우는 데 어떻게 도움이 되는지 보여주는 이야기를 들려드리고 싶습니다 . 이는 OOP 의 목적을 이해하는 데 필요합니다 .

옛날 옛적에 은하계 운송 서비스를 제공하는 작은 회사가 있었습니다...

갤럭시 러쉬라고 부르자. 5명을 채용했습니다. 한 사람은 금융, 두 번째는 창고, 세 번째는 배송, 네 번째는 광고, 다섯 번째는 기업 전체를 관리했습니다.

그들은 매우 열심히 일했고 모든 일에 성공했습니다. 그 회사는 좋은 평판을 얻었고 많은 돈을 벌었습니다. 하지만 해마다 점점 더 많은 주문이 들어왔기 때문에 사장은 직원을 추가로 고용해야 했습니다. 창고용으로 몇 개 더, 배송용으로 몇 개 더, 금융용으로 한 개 더, 그리고 회사의 시장 점유율을 확대하기 위해 광고 전문가를 추가했습니다.

그리고 그때 문제가 시작되었습니다. 더 많은 사람들이 있었고 그들은 서로를 방해하기 시작했습니다.

마케터는 새로운 광고 캠페인에 은행 계좌를 소모하므로 긴급하게 배송해야 하는 제품을 구입할 돈이 없습니다.

창고에는 한 달에 한 번 고객에게 배송되는 10개의 새로운 하이퍼 드라이브가 있습니다. 한 택배기사가 날아와 다른 클라이언트의 하이퍼 드라이브를 가져갔고, 이로 인해 하이퍼 드라이브 10개의 정기 주문이 한 달 지연되었습니다. 첫 번째 배달원은 두 번째 배달원이 다른 주문을 채운다는 사실을 몰랐습니다.

새로운 대리는 더 많은 상품을 구매하기 위해 우주선에 택배를 보냅니다. 한편 다른 모든 사람들은 사용 가능한 우주선이 나타나기를 기다립니다. 긴급 배송이 엄청나게 많은데, 이 조수는 조달만 감독하고 맡은 일을 잘 해내려고 노력하고 있습니다. 직원이 자신의 직무를 잘 수행할수록 다른 사람의 업무에 더 많이 간섭합니다.

상사는 상황을 분석하면서 우주선, 현금, 제품과 같은 중요한 자원이 최적으로 사용되지 않고 있음을 깨닫습니다. 대신 "잠을 자면 패배"라는 규칙이 적용됩니다. 모든 직원은 다른 모든 사람이 업무에 필요한 리소스를 가져갈 수 있으므로 다른 직원과 회사 전체를 위험에 빠뜨릴 수 있습니다.

뭔가 조치를 취해야 했기 때문에 사장은 모놀리식 회사를 몇 개의 부서로 나누기로 결정했습니다. 그는 운송 부서, 마케팅 부서, 조달 부서, 재무 부서 및 재고 부서를 만들었습니다. 더 이상 아무나 단순히 우주선을 탈 수 없습니다. 배송 부서장은 배송에 대한 모든 정보를 받고 가장 수익성이 높은 주문으로 택배에 배송했습니다. 또한 창고는 택배원이 원하는 상품을 단순히 가져가는 것을 허용하지 않았습니다. 대신 창고에서 제품을 선택하는 것이 통제된 프로세스가 되었습니다. 재무 부서는 곧 구매가 있을 것이라는 것을 안다면 마케팅 캠페인을 위한 자금을 공개하지 않을 것입니다. 각 부서는 하나의 공개적인 얼굴, 즉 부서장을 가졌습니다.각 부서의 내부 구조는 자체 사업이었습니다. 택배기사가 물건을 받고 싶으면 창고가 아닌 창고관리자에게 갔다. public-facing representative새로운 주문이 들어오면 택배기사( )가 아닌 배송부장( someone not authorized to interact with the other departments) 이 받았다 .

즉, 상사는 리소스와 리소스 관련 작업을 그룹(부서)으로 통합 하고 다른 사람이 부서의 내부 구조에 간섭하는 것을 금지했습니다. 부서 간 상호 작용은 특정 사람을 거쳐야했습니다.

OOP 의 관점에서 이것은 프로그램을 객체로 나누는 것에 지나지 않습니다 . 메서드와 변수의 모놀리식 프로그램은 개체로 구성된 프로그램이 됩니다. 그리고 개체에는 변수와 메서드가 있습니다.

문제는 모든 직원이 감독이나 통제 없이 모든 리소스로 작업하고 다른 직원에게 명령을 내릴 수 있다는 것입니다. 우리는 약간의 제한을 두었지만 더 많은 질서를 달성했습니다. 그리고 우리는 또한 모든 것을 더 잘 제어할 수 있었습니다.

이것은 가장 순수한 형태의 분할 정복입니다.

2. 프로그램 생성 방법

OOP 의 또 다른 장점을 드러내는 또 하나의 중요한 포인트를 건드리고자 합니다 . 프로그램이 건물보다 동물에 더 가깝다는 것을 알고 있습니까? 그들은 지어지지 않았습니다. 그들은 성장합니다. 개발은 끊임없는 변화입니다. 건설에서는 좋은 계획을 세우고 정확하게 따를 수 있습니다. 소프트웨어 개발에서는 그렇지 않습니다.

프로그래밍을 하다 보면 원래 의도한 대로 무언가를 할 수 없고 많은 재작업을 해야 하는 경우가 많습니다. 고객 요구 사항은 훨씬 더 자주 변경됩니다.

하지만 고객이 매우 정확한 사양을 제공했다면 어떨까요? 그것은 상황을 더욱 악화시킵니다. 시간이 지남에 따라 제품에 어떤 일이 발생하는지 살펴보십시오.

제품의 성공으로 인해 고객은 새 버전을 출시하고 또 다른 버전을 출시하기를 원할 것입니다. 물론 기존 제품에 "작은 변화"를 추가하기만 하면 됩니다. 따라서 제품 개발은 끊임없는 변화의 연속임을 알 수 있습니다. 시간 척도만 다를 뿐입니다. 새 버전은 일주일에 한 번, 한 달에 한 번 또는 6개월에 한 번 출시될 수 있습니다.

이 모든 것에서 우리는 어떤 결론을 이끌어낼 수 있습니까? 제품의 내부 구조는 최소한의 재작업으로 상당한(그리고 사소한) 변경을 허용하는 방식으로 유지 관리되어야 합니다.

개체 응집력

그러나 그렇게 하는 것은 그것을 하기로 결정하는 것보다 더 어렵습니다. 우리는 이미 프로그램이 서로 상호 작용하는 개체로 구성되어 있다고 말했습니다. 프로그램의 모든 개체를 점으로 표시하여 보드에 그려 봅시다. 그리고 각 개체(점)에서 상호 작용하는 다른 모든 개체(점)로 화살표를 그려 봅시다.

이제 개체(점)를 그룹으로 결합합니다. 점 사이의 연결이 다른 점보다 훨씬 더 강한 경우 점을 그룹화해야 합니다. 한 지점에서 대부분의 화살표가 자체 그룹의 다른 지점으로 이동하면 그룹이 올바르게 형성된 것입니다. 그룹 내의 포인트는 응집력이 높고 다른 그룹의 포인트는 응집력이 낮습니다.

느슨한 결합 원리

"느슨한 결합의 원리"가 있습니다. 프로그램은 종종 계층인 여러 부분으로 나뉩니다. 이러한 레이어/부분의 논리는 내부 구조에 밀접하게 연결되어 있고 다른 레이어/부분에는 매우 느슨하게 연결되어 있습니다. 레이어 간의 상호 작용은 일반적으로 매우 규제됩니다. 한 계층은 두 번째 계층을 참조하고 해당 클래스의 작은 하위 집합만 사용할 수 있습니다. 이것은 앞에서 본 "회사를 부서로 나누는 것"의 원칙이지만 더 큰 규모입니다.

그 결과 필요에 따라 부서를 재구성하여 효율성을 높일 수 있고 부서에 더 많은 사람을 고용할 수 있습니다. 다른 부서와의 상호 작용 프로토콜을 변경하지 않는 한 모든 변경 사항은 지역에 남아 있습니다. 아무도 아무것도 다시 배울 필요가 없습니다. 전체 시스템을 재작업할 필요가 없습니다. 각 부서는 부서 간 상호 작용을 위한 메커니즘을 잘 선택하면 이러한 종류의 내부 최적화를 수행할 수 있습니다.

잘 선택했습니다. 그러나 그들이 잘 선택되지 않는다면? 그러면 변경 용량이 빠르게 고갈되고 전체 시스템을 다시 실행해야 합니다. 이것은 수시로 이루어져야 합니다. 미래를 예측할 수는 없지만 재실행 횟수를 최소한으로 유지할 수 있습니다.

추상화의 원리

부서가 구성되고 상호 작용하는 방식을 선택하는 것이 " 추상화 원칙 "입니다. 프로그래밍에서 프로그램을 구성 부분으로 나누는 최선의 방법과 해당 부분이 상호 작용하는 방법을 결정하는 데 사용됩니다. 프로그램을 개별 클래스로 나눌 때까지 결과 부분을 부분으로 나누는 원칙을 다시 적용할 수 있습니다.

이러한 부분의 내부 구조를 숨기고 다른 부분과의 상호 작용을 엄격히 제한하는 것이 캡슐화 입니다 . 캡슐화와 추상화는 OOP 의 초석입니다 . 좋은 프로그램은 이 두 가지 원칙을 따라야 합니다. 앞으로 우리는 나머지 원칙들을 살펴보고 그들이 제공하는 이점을 탐구할 것입니다.