객체지향과 절차지향? 무엇을 선택할까

이 포스트는 인프콘 2024 조영호님의 발포 "객체지향은 여전히 유효한가?" 를 보고 작성한 포스트입니다.

 
 

집에서 인프콘 참여하기

 

 

🐳 객체지향은 여전히 유효한가 ?

---

함수형 프로그래밍, 절차지향, 객체지향, 멀티 패러다임 등 여러 프로그래밍 패러다임이 성행하고 있다.

그렇다면 아직도 객체지향은 유효할까 ?

이 질문에 대해 발표자 조영호 님은 객체지향이 "여전히" 유효한가 보다 "언제" 유효한가에 대해서 고민하는 것이 옳지 않을까라는 대답을 해주셨다.

공학에 은탄환은 없기에 선택한 기술의 장단점을 알고 현재 상황에 필요한 것을 올바르게 선택하는 능력이 중요하다는 것이다.

 

그렇다면 객체지향과 절차지향은 언제 선택하는 것이 좋을까 ?

 

🐳 객체지향과 절차지향의 차이

---

객체지향의 큰 특징으로 캡슐화와 다형성을 꼽을 수 있을 것이다.

 

먼저 간단하게 캡슐화와 다형성을 알아보자

먼저 객체지향은 데이터와 메소드를 캡슐화한다.

이는 불필요한 데이터의 노출을 최소화하고 인터페이스만을 노출한다는 장점이 있다.

결국 메소드에 사용되는, 또는 객체가 필요로 하는 데이터만을 가지고 있는 것이다.

 

또 객체지향은 인터페이스를 이용해 다형성을 구현한다.

같은 메소드를 수신할 책임이 있다면 어떤 객체가 와도 상관이 없기 때문에 다형성을 이용해서 도메인 규칙을 확장하는데 용이하다.

 

설명을 봤을 때 단점이라고는 없어 보인다.

하지만 이러한 특징 또한 완벽할 수만은 없다

 

이 두 가지 특성이 절차지향과 어떻게 다른 점을 만들어 내는지 알아보자

 

캡슐화의 단점

만약에 예약 시스템의 데이터를 가공하기 위해서 schedule, product, reservation 데이터가 필요하다고 가정해보자

데이터가 전부 캡슐화 되어 있다면 아래와 같이 각각의 객체에서 필요한 정보를 꺼내야 할 것이다.

const schedule = bookingSchedule.schedule
const product = bookingProduct.product
const reservation = bookingExternal.reservation

 

이렇게 각각의 객체에서 필요한 정보를 꺼내어 가공을 해야한다는 번거로움을 겪게 된다.

 

이렇듯 캡슐화는 데이터를 가공하는 입장에서 생각했을 때는 필요한 데이터들이 각각의 객체, 캡슐에 나뉘어 있기 때문에 데이터를 한 번 꺼내서 가공을 해야한다는 단점이 있다.

데이터를 가공하는 곳에서는 객체지향이 불편할 수 있다는 것이다.

 

다형성의 장단점

다형성은 객체지향이 가진 큰 강점이다.

하지만 다형성 또한 언제나 좋은 방법일까 ? 당연히 아닐 것이다.

그렇다면 다형성은 언제 좋고 언제 좋지 않을까 ?

 

다형성은 기능의 확장에 유리하다 !

기능의 확장이 무슨 의미인지 와닿지 않을테니 아래의 설명을 보자

 

근태관리 시스템을 구현하고 있다고 가정해보자.

 

근무 규칙이라는 인터페이스를 생성해서 오전 근무 규칙과 오후 근무 규칙을 구현했다.

이 상황에서 야근에 대한 근무 규칙을 구현해야 한다면 어떻게 구현하면 될까 ?

같은 WorkingRule 인터페이스를 구현하는 Evening Rule 을 추가하면 될 것이다.

여기서 중요한 것은 기존의 Morning Rule, Afternoon Rule 에는 아무런 영향이 없다는 것이다 !!!

이렇듯 기능의 확장에 유리하다는 것은 다른 기능의 수정 없이 새로운 기능을 구현하기에 유리하다는 것이다.

 

하지만 이러한 다형성도 완벽한 것은 아니다.

다형성은 기능을 추가할 때는 좋지 않다.

 

만약 근태관리 시스템의 요구사항으로 새로운 기능을 추가해야 해서 WorkingRule 에 새로운 메소드를 추가해야 한다고 하자.

그러면 기능 추가를 위해서 Morning Rule, Afternoon Rule, Evening Rule 모두에 새로운 메소드를 구현해야 할 것이다.

 

이는 절차지향에서 기능을 추가할 때보다 오히려 변경점이 더 커지게 되는 것이다.

이러한 관점에서 봤을 때 기능의 확장보다 기능의 추가가 더 많은 도메인은 객체지향보다 절차지향이 더 좋은 선택이 될 수 있다는 것이다.

 

 

🐳 그래서 언제 객체지향 / 절차지향을 선택할까 ?

---

 

정리하자면 아래와 같다.

 

절차지향

• 데이터 가공 작업에 유리하다
• 기능의 추가에 유리하다

객체지향

• 기능의 확장에 유리하다.
• 데이터를 캡슐화 해 변경에 유연한 설계를 가져갈 수 있다.

 

결론적으로 항상 완벽한 기술은 없는 것처럼

내가 현재 해야하는 작업이 어떤 성향을 띄는지 확인하고 필요에 따라 알맞은 기술을 선택하도록 하자 !