[객체지향과 스프링의 이해] 7. 마치며

이 글은 2023 GDSC Sookmyung Core Member Session을 텍스트로 정리한 것입니다. (사실 대본 작성하는 김에 쓴거예요-!!) 영상으로 보고 싶으신 분들은 이 링크를 참고해주세요. 대부분의 내용은 조영호 님의 <객체지향의 사실과 오해>, <오브젝트>, 이일민 님의 <토비의 스프링 vol1>을 참고했습니다.

---

 

지금까지 객체지향의 목적과 가치, 스프링으로 객체지향적인 비즈니스 로직을 작성하는 방법까지 알아보았습니다. 이번 포스팅은 세션을 마무리하며, 이번 발표에서 다루지 못한 내용을 키워드 위주로 다룹니다.

 

 

객체지향적인 사고는 오브젝트가 자신의 행동에 충실하도록 응집도를 높여서 독립적으로 만드는 작업에서 출발합니다. 이 작업을 오브젝트보다 넓은 영역에서 적용할 수 있는데, 모듈화라고 부릅니다. 모듈화의 단위는 오브젝트보다 작아도 되고, 더 커도 됩니다.

 

 

기능을 작게 쪼개서 메소드에 할당하면 그 메소드는 하나의 책임을 수행하도록 모듈화됩니다. 이 모듈을 오브젝트로 확장하면 객체지향이고요, 애플리케이션 계층으로 확장하면 아까 살펴본 3 tier 계층 구조가 되고요, 기능을 좀더 큰 단위인 컴포넌트로 만들어 재사용하면 CBD(component based development), 컴포넌트를 모아서 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화하는 방법을 SOA(service oriented architecture), 데이터 저장소까지 캡슐화해서 완전 독립적인 서비스로 모듈화하는 방법을 MSA(micro service architecture)라고 부릅니다.

 

 

아직 위의 주제들을 다루지 못해서 아쉬움이 남습니다. 조금 더 공부해서 카페 예제에 적용하는 과정을 이후에 포스팅하겠습니다(언젠가는….). 일단 키워드 위주로 짧게 다루어보겠습니다.

 

 

책임 주도 설계는 애초에 애플리케이션을 설계할 때 객체의 협력 관점에서 설계하는 방법을 의미합니다. 객체지향의 3대 요소(협력, 책임, 역할) 중에 가장 중요한 것은 책임입니다. 협력이 중요한 이유는 객체의 행동을 결정하는 맥락이기 때문이고, 역할은 객체의 책임을 추상화한 것이기 때문입니다. 그래서 애플리케이션을 설계할 때 기능을 수행하기 위해 필요한 메시지는 무엇인지 생각하고, 이 메시지는 어떤 객체가 받을지 결정합니다. 이 객체에서 또 필요한 메시지는 무엇이고 객체에게 할당하는 작업을 연쇄적으로 진행합니다. 이렇게 행동을 먼저 생각하고 객체를 결정하면, 자연스럽게 객체들의 협력 흐름과 함께 최소한의 인터페이스를 얻을 수 있습니다. 이때 사용할 수 있는 다이어그램 도구가 UML입니다.

 

 

디자인 패턴은 어떤 상황에서 자주 사용되는 객체지향적인 기법을 패턴으로 정리한 것입니다. 디자인 패턴을 공부할 때는 어떤 맥락에서 사용되는지, 어떤 구현 방식을 사용하는지 알아야 합니다. 더 본질적인 것은 어떻게 캡슐화를 했고 응집도를 높이고 결합도를 낮췄는지 알아볼 수 있어야 합니다.

 

 

SOLID 원칙은 로버트 마틴이 제시한 객체지향 프로그래밍 및 설계의 다섯 가지 기본 원칙입니다. 처음 볼 땐 굉장히 낯설고 추상적으로 느껴지는 내용이지만, 객체지향의 핵심 원리를 이해하고 나면 당연하면서도 굉장히 유용한 가이드라인입니다.

 

 

자바나 디자인패턴을 공부해보셨다면 상속보다는 합성을 사용하라는 말을 많이 들어보셨을 것 같은데요, 이 말은 객체 사이의 관계를 맺어서 코드를 재사용할 때 유효합니다. 상속은 객체의 서브 타입을 만들 때 유용합니다. 서브 타입은 자식이 부모로 객체되어도 동일한 메시지를 이해할 수 있어야 하고, 자식에서 추가로 정의한 메소드는 상위 협력 흐름에서 사용할 수 없으므로 사용하지 말아야 합니다. 이 내용은 리스코프 치환 원칙에서 더 자세히 다룹니다.

 

 

위의 내용들은 더 공부해서 카페 예제에 적용해보도록 하겠습니다. 그럼 그때까지 안녕.. 긴 시리즈 읽어주셔서 감사합니다.