객체가 자율적이면 뭐가 좋을까

객체 지향 패러다임의 핵심은 상속이 아니라 자율적인 객체들끼리의 협력이다. 여기서 자율은 어떻게 나오는 것일까.

 

캡슐화와 자율성 

객체의 자율성은 객체의 외부와 내부를 판가름하는 데에서부터 나온다. 우선 객체A는 자신의 프라이버시를 외부로부터 지키기위해 (간섭하거나 접근할 수 없도록) 차단해야한다. 객체 외부B는 접근이 가능한 수단을 통해서만 해당 객체A와 협력을 맺을 수 있다. 이 협력을 통해 객체 B는 객체 A 가 무엇을 수행하는지는 알 수 있지만, 어떻게 수행하는지에 대해서는 객체 A의 프라이버시이므로 알 필요가 없다. 우리는 이것을 객체(A)의 캡슐화=정보은닉이라고 부른다. 

 

응답과 요청, 협력 발생

캡슐화를 통해 객체의 자율성을 확보하는 이유는 무엇일까. 객체는 자기자신을 주체적으로 변경할 수 있어야하기 때문이지 않을까. 왜 주체적으로 변경할 수 있어야할까? 내가 어떻게 커피를 만드는지는 공개하지않고 어째됐든 손님이 커피를 제공받을 수 있는 것만 생각해보았다. 여기서 공용인터페이스는 커피를 요청하고, 커피를 제공받는(응답)인 것이다. 공용 인터페이스를 통해 객체들끼리의 연쇄적인 요청과 응답이 오고가는 것 = 협력이 일어난다. 이때의 응답과 요청은 단순하고 이해하기 쉽다. 다른 방식으로 커피를 만들어도 상관없다. 그건 객체 개개의 책임이고 자율이다. 커피만 만들고 제공하면 끝이다! 언젠가 커피에 우유를 넣든 크림을 넣든 협력하고 있는 객체가 누구냐에 상관없이 유연하게 변경할 수 있게된다. 

 

객체가 단순하면 또 뭐가좋을까? : 단 하나의 약속으로 맺어진 계약 그리고 SRP 

단순하면 추상화시키기 쉽지않을까? 복잡함을 덜기위해 책임을 분리하는 시도가 일어나지 않을까? 새로운 객체가 그 안에서 발견되지않을까? 책임과 역할을 하나로만 가져갈 수 있게 되지않을까? 하나의 메세지를 통해 계약맺어진 협력들을 더 이해하기 쉬워지지않을까?

 

SRP 얘기도 여기서 나옴직함하다. 자잘한 단일 클래스가 많아지는 것 vs. 큰 클래스가 몇 개 있는 것 중에 어떤 것이 더 좋을까? 어떤 것이 협력을 더 이해하기 쉽게 하는 것일까? 큼직한 다목적 클래스 몇 개로 이뤄진 시스템은 변경을 가할 때 당장 내가 알 필요 없는 것들까지 눈에 보여서 코드 읽기를 방해한다. 작은 클래스는 변경할 이유가 적어지고 따라서 집중적으로 코드 해독이 쉬워진다. 응집도가 높아지고 결합도는 낮아진다!!!!

 

 

 

키워드를 코드로 한번 살펴보았다. 

 

 

🗣 책임이 자율적일수록 적절하게 '추상화'되며 '응집도'가 높아지고, '결합도'가 낮아지며, '캡슐화'가 증진되고, '인터페이스와 구현이 명확이 분리' 되며, 설계의 '유연성'과 '재사용성'이 향상된다.