이전 포스팅에서 객체지향 프로그래밍이 등장하게 된 배경을 기반으로 OOP 의 핵심 키워드와, 4가지 큰 특징에 대해서 알아보았다. 이번 포스팅에선 객체지향 프로그래밍의 특성과 장점을 최대한으로 끌어올리기 위해 프로그램을 어떻게 설계해야 하는 지에 대한 이야기를 다뤄본다.

객체지향 설계과정

1. 요구사항 (제공해야 할 기능) 을 찾고 세분화 한다. 그리고 그 기능을 알맞은 객체로 할당한다.
2. 기능을 구현하는 데에 필요한 데이터를 객체에 추가한다.
3. 해당 데이터를 이용하는 기능을 구현한다. (기능은 최대한 캡슐화)
4. 객체 간에 어떻게 메소드 호출을 주고받을 지 결정한다.

객체지향 설계원칙

흔히 SOLID 라고 부르는 5가지 설계원칙이 존재한다. 솔직히 원문 그대로 해석하면 외계어가 따로 없다. (공돌이의 한계인 듯 하다) 하나씩 살펴보도록 하자. 같은 개념을 반복하여 풀어나가는 방식을 택했기 때문에, 이해가 될 때까지 설명을 읽어보고 다음 개념으로 넘어가도 좋다.

SRP (Single Responsibility) 단일 책임 원칙

• 클래스는 단 한개의 책임을 가져야 함
• 클래스를 변경하는 이유는 단 하나여야 함
• 이를 지키지 않으면, 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향을 미칠 수 있음→ 이렇게 되면 유지보수가 매우 비효율적

🤔 책임 이라는 말이 너무 추상적이다..

SRP 에서 이야기하는 책임이란, '기능' 정도로 생각하면 된다. 만약 한 클래스가 수행할 수 있는 기능 (책임) 이 여러 개라면, 클래스 내부의 함수끼리 강한 결합을 발생할 가능성이 높아진다. 응집도는 높고 결합도는 낮은 프로그램을 설계하는 것이 비로소 객체지향 설계의 핵심인데, 이것이 위반되는 것이다. 새로운 요구사항이나 프로그램 변경에 의해 클래스 내부의 동작들이 연쇄적으로 변경되어야 할 수도 있다. 이는 유지보수가 비효율적이므로, 책임을 잘게 쪼개어 분리시킬 필요가 있다.

예를 들어 어떤 클래스내에 A 라는 메소드가 있고, 이 A 메소드는 A 메소드의 결과를 기반으로 B 메소드를 호출하며, B 메소드는 B 메소드의 결과를 기반으로 C 메소드를 호출하도록 구현이 되어있다고 해보자. 이 때 만약 A 메소드의 동작이 일부 수정된다고 할 때, B 와 C 메소드를 전부 바꿔야 할 상황이 발생할 수 있다. 유지보수가 매우 비효율적인 것이다. 따라서 이들을 모두 분리할 필요가 있다.

OCP (Open-Closed) 개방-폐쇄 원칙

• 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 함
• 즉, 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야 함
• 이를 지키지 않으면 instanceof 와 같은 연산자를 사용하거나, 다운 캐스팅 발생

어떤 모듈의 기능을 하나 수정할 때, 그 모듈을 이용하는 다른 모듈들 역시 줄줄이 고쳐야 한다면 유지보수가 복잡할 것이다. 따라서 개방 폐쇄 원칙을 잘 적용하여 기존 코드를 변경하지 않아도 기능을 새롭게 만들거나 변경할 수 있도록 해야 한다.