[item03] OOP와는 거리가 먼 Utility Class

[JHZLO]

item 04를 공부하다보니 이전에 우테코 미션 중 Utility Class를 불가피하게 썼어야 했던 때가 떠오르네요.

처음에는 Utility가 객체지향과는 거리가 멀다 생각하였고,
최대한 안쓰려는 방향대로 진행하려던 기억이 있는데요.

이제와서 생각해보니 utility class는 어쩌면 객체지향언어의 단점을 보완해주는 강력한 녀석이라는 생각도 동시에 드는 것 같습니다.

즉, 남용하지 않고 적절히 사용한다면 코드를 더욱더 간결하게 만들 수 있도록 하는 것 같습니다.

이렇게 생각을 가지는 동안 문득 다음과 같은 "본질적인 질문"이 떠올랐습니다.

Important

Utility Class가 객체지향과 거리가 먼 이유가 뭘까?

이 부분에 대해서 한 번 이야기 나누면 객체 지향의 목적 그리고 원리를 다시 한 번 상기시킬 수 있는 좋은 기회라 생각이 들어 토론으로 올려봅니다.
(저도 어느정도 답변은 생각해보았는데, 미리 말하면 소재를 가로채기하는 느낌이라 답글이 달리면 그 떄 의견을 던져보겠습니다)

[digitpic]

제가 아는 가장 큰 이유는 아래와 같습니다

유틸리티 클래스는 static 으로 선언되니
모든 객체가 이에 대한 존재를 알고 있게 되며
이로 인해 캡슐화가 깨지게 된다

캡슐화가 깨지면서 객체지향이 깨지기에 객체지향과 거리가 멀다

---

그 외에도 생각해보면 상태를 가지지 않는다 가 있는 거 같아요
상태를 가지고 변화해야 살아있는 객체지, 상태가 없으면 객체라고 하기 어려울 거 같다고 생각해요

---

비즈니스 로직과 거리가 멀다 라는 생각도 드는데
비즈니스 로직을 처리하는 유틸리티 클래스를 만드는 게 좋은 경우도 있을까요?

이 부분에 대해서 어떻게 생각하시는지 궁금합니다

[JHZLO]

오 ! 다양한 이유들로 너무 잘 답변해주신 것 같습니다!

저도 규원님과 비슷하게 아래와 같이 생각했습니다.

객체지향언어는 객체들이 서로 소통하며 비즈니스 로직을 처리해나가는 언어인데,
이때 가장 중요한 특징 중 하나가 각 객체가 상태를 가지며 행위를 통한 상태 변화를 통해 런타임 중의 코드의 흐름을 만들어 내는 것이라고 생각합니다.
그러나 유틸리티 클래스 같은 경우에는 상태가 정의되지 않아 이러한 특징을 반영하지 못하고,
다른 객체들이 유틸리티 클래스의 메서드를 아무런 인스턴스 생성 없이 그냥 가져다가 사용할 수 있으므로 오히려 절차지향적인 느낌이 강하다 생각이 들었습니다.

---

비즈니스 로직을 처리하는 유틸리티 클래스를 만드는 게 좋은 경우도 있을까요?

해당 질문을 듣고 비즈니스 로직에 대한 개념이 모호한 것 같아 다시 찾아봤는데, 아래와 같다고 합니다.

소프트웨어 공학에서 도메인, 비즈니스라는 말은, '소프트웨어가 풀고자 하는 현실 세상의 문제'를 가리킨다.
'도메인 로직'이나 '비즈니스 로직'이라고 말할 때는, 그 '현실 세상의 문제'를 해결하는 코드를 의미한다. 

그렇다면 비즈니스 로직과 도메인 로직의 차이점은 무엇일까?

• 비즈니스 로직 : 비즈니스 프로세스와 전체 워크플로우
• 도메인 로직 : 특정 문제 영역(도메인)의 규칙, 계산, 규약

정리하자면 도메인 로직은 "문제를 어떻게 해결할 것인가"에 집중하고,
비즈니스 로직은 "문제를 언제, 어떤 순서로 처리할 것인가"에 초점을 맞추는 것이라고 합니다.

---

그럼 이제 다시 본론으로 돌아와서, 규원님의 질문에 대한 결론부터 말씀드리자면
유틸리티 클래스는 비즈니스 로직과 거리가 멀지 않다. 라고 생각이 듭니다.

위의 내용을 제가 이해한 바에 따르면, 유틸리티 클래스는 "문제를 어떻게 해결할 것인가"에 해당이 되는데요.
그렇다면, 유틸리티 클래스는 도메인 로직에 해당할 것이고,
도메인 로직은 비즈니스 로직의 흐름을 만들어내는 데에 중요한 역할이므로. 유틸리티 클래스는 비즈니스 로직의 일부라고 생각합니다.

---

Important

유틸리티 클래스는 객체지향적인 특성과 거리가 멀다. 그럼에도 불구하고 유틸리티 클래스를 사용해야만 하는 이유가 있다면 무엇일까?

규원님은 유틸리티 클래스가 비즈니스 로직과 거리가 멀다고 생각한 이유가 무엇인지,
그리고 위의 질문에 대해서는 어떻게 생각하시는지 궁금합니다!!!

[digitpic]

도메인 로직을 비즈니스 로직에 포함시켜 말씀드렸어요!
제대로 구분해보면 유틸리티 클래스는 도메인 로직과는 거리가 멀다라는 이야기를 드리고 싶었습니다

도메인 로직과 가까운 로직들은 모델에 들어가야 한다고 생각하는데,
도메인 로직이 유틸리티 클래스에 포함되는 게 더 좋은 경우가 있을까? 라는 의문이 듭니다