정적 유틸 클래스는 어떤 기준으로 만들어야 할까? #11
Replies: 1 comment
-
발제콜리 : 그래서 이번 주제는 `정적 유틸 클래스는 악인가? 에 대한 논의입니다. static method가 객체지향 스럽지 않다는 것은 저도 알고 있어요. 그럼에도 반복되는 간단한 공통 코드에 대해서 유틸 클래스의 효율성 또한 부정하기는 어렵다고 생각합니다. 그렇다면 유틸리티 클래스를 적용하는 각자의 기준은 어떻게 되시나요? PART1. 여는 발언콜리 : 나는 유틸 클래스가 메모리 효율적인게 필요없는 인스턴스들이 둥둥 떠나닐 필요가 없어. 그리고 도메인 여러 곳에서 필요한 로직이라면 의존성으로 그 객체를 받거나 필드로 가지고 있어야 하는데 그게 굉장히 비효율적이라 생각해. 리비 : 스프링에서는 실제로 많은 유틸리티 클래스를 운영을 하고 있는 걸보면 유틸 클래스가 절대악이라는 생각은 스프링도 나도 가지고 있지 않은 것 같아. 개인적인 유틸 클래스의 기준은 도메인 맥락이 모두 빠진 편의 목적의 로직이야. 제리 : 나도 리비와 비슷한 의견인데, 제이슨이 말씀해주셨던 유틸 클래스의 기준에 동의해
그럼에도 무지성으로 유틸을 붙였을 때 OOP와 빠르게 멀어질 수 있다는 것을 프리코스를 통해 배웠기 때문에 유의해야겠지만 유틸 클래스가 악이라고 생각하진 않아 에버 : 나도 유틸 클래스가 악이라고는 생각하지 않아. 나의 기준은 도메인 로직의 부재도 있고, 하나의 클래스에서만 쓰이는 게 아니라 일반적으로 사용되어 충분히 재사용가능한지도 기준에 있는 것 같아. 유틸 클래스에는 도메인 로직이 왜 포함되지 말아야 하는가?콜리 : 그럼 왜 비즈니스나 도메인 로직은 유틸 클래스에 포함하면 안되는 걸까? 같은 인풋에 아웃풋이 나가는 상황이고, 도메인 내 곳곳에서 쓰인다면 유틸 클래스가 되지 말야아 하는 걸까? 에버 : 도메인 로직이 들어 있는데 그걸 static화 하면 그만큼 확장성이 떨어지고 재사용할 수 있는 범위를 줄인다고 생각해. 콜리 : 그럼 확장의 가능성이 희박하다면? 리비 : 그럼에도 비즈니스 로직이 유틸에 들어가지 말아야 할 이유는 꽤 자명하다 생각해. 우리가 OOP를 하고 있기 때문이야. 객체지향은 객체에서 메시지가 드러나야 하는데 static 클래스는 객체가 생성되지도 않았는데 메시지를 가지고 있어. 그렇기 때문에 사용자 입장에서는 메시지를 찾아가기가 매우 힘들지. 우리는 객체로부터 메시지를 읽으려 하고, 그로부터 도메인 명세를 읽으려는데 그 명세가 생성되지도 않은 유틸 클래스 내에 숨어 있으니까 굳이 유틸 클래스를 사용해야 하는 이유?콜리 : 그럼 OOP를 지향하는 세계관에서 우리가 굳이 유틸 클래스를 선언해야 하는 이유가 있을까? 사실 객체 만들어서 메시지를 보내면 되는 거잖아. static 선언은 구조 변경이 쉽지 않고, 절차 지향적 패러다임으로부터 온 것이라는 이야기도 있었어. 객체로부터 물어보기보다 기능이 필요하면 static 호출해서 쓰는 방식이니까. 객체 세상에서는 객체들의 메시지 전달로 로직이 구성되어야 하는데 신적인 누군가에게 의존하는 느낌이 드는 것이지 리비 : 객체 지향으로부터의 사고가 유틸 클래스를 계기로 멀어질 수 있다고 한 것이라면 나는 동의해. 그런데 우리가 어느 정도 프로그래밍을 알고 있는 상황에서 유틸을 쓰면 굉장히 편하지 않아? 객체를 선언하고 만드는 것도 결국 일이잖아. 그런데 유틸 클래스는 그런 고려사항이 전혀 없어 제공하는 기능을 쓰기만 하면 되거든. 또, 유틸 클래스의 기원이 절차지향이라는 이야기도 동의하지 않아. 자바가 함수형 프로그래밍을 부분적으로 포용한 것처럼 편의를 위해 사용가능한 부분이라 생각해. 콜리 : 그럼 유틸 클래스가 너무 많은 걸 열어준다고 생각하진 않아? 예를 들어 Collections 하고 점 누르면 거기 있는 거 다 사용할 수 있는 거잖아. 그런데 객체를 선언하면 우리가 원하는 기능만 호출하고 동작하는 것이 보장되는 거지 리비 : 그건 사용하는 사람의 책임이 크다 생각해. 청소기 이론은 옳은가?리비 : 내가 만든 청소기 이론이 있는데 내가 에버한테 청소기를 팔았어. 근데 에버가 청소기를 분해해서 로켓을 만들었어. 근데 로켓이 발사가 안된다고 항의를 하러 왔다면 나는 책임이 있을까? 제리 : 나는 이해가 안되는게 에버가 청소기를 샀어. 거기에 빨간색으로 동그라미 버튼을 만들어놓았다며 누르고 싶어 안누르고 싶어? 에버 : 누르고 싶지 제리 : 청소기가 펑 터지면 황당하지 않아? 딱 봐도 사용자가 사용할 수 없는 상태로 청소기를 배포해야지 리비 : 그거는 우리가 누르지 말라고 명세에다 써줘야지 제리 : 근데 사용자가 예측하지 못하는 행동을 한다고 해도 딱봐도 하면 안될 거를 우리가 주면서 하지말라고 하는 건 아니라 생각해 리비 : 나는 사용하는 사람이라 생각해. 우리는 개발 코드를 사용하는 입장에서 이것도 할 수 있고, 저것도 할 수 있지만 그걸 선택하는 건 개발하는 사람의 책임이지 다시 돌아가서 나는 편의 기능이 많이 열려 있는 건 잘못이 아니라 생각하고 걱정할 필요가 없다고 생각해. 오히려 많을 수록 좋고, 어떤 것을 골라 쓸지는 쓰는 사람 책임이라 생각해 닫는 발언제리 : 저는 유틸 클래스가 악이라는 의견에는 반대해요. 그렇지만 유틸 클래스를 어떤 제한도 없이 사용했을 때 OOP로부터 멀어진다는 의견도 납득이 가거든요. 유틸로 빼는건 재밌고 쉬워요. 그런데 빼다보면 객체가 하는 일이 없어질 수 있겠죠. 충분히 각자 유틸에 대한 기준이 있고 또 그게 일반적으로 동일한 것 같아서 이 정도 규칙을 가지고 코드를 짠다면 큰 문제는 없을 것 같아요. 에버 : 나는 유틸 클래스가 더욱 좋아졌는데 나는 OOP보다 메모리 낭비를 하지 않는 것이 중요하다고 생각하거든? 정확히는 하나의 로직을 위해 한번 쓰고 버릴 객체들을 계속 생성하는게 메모리만 차지하고 있는 것 같아서 싫어. 콜리 : 나는 세가지 원칙이 일반적인 것 같아
다만 비즈니스 코드를 정의하는 기준이 다르다보니 서로 유틸 클래스로 빼도 된다, 아니다로 의견이 나뉘게 되는 것 같아. 발제자 회고유틸 클래스에 대한 공통된 기준을 가지고 있음에 놀랐습니다. 그럼에도 토론을 하며 느꼈던 것은 악마의 논증처럼 무언가가 좋다는 것을 이야기하는 것은 쉽지만, 그로부터 발생하는 잠재적인 손실은 묘사하거나 그려내기가 힘들다는 사실입니다. 유틸 클래스로 부터 얻는 이득과 좋은 점은 직관적이어서 논증하기 쉽지만 그로부터 발생하는 OOP의 손실은 예시가 없다면 토론 장에서 생경하게 그려내기 힘든 부분이 있었습니다. 그럼에도 유틸 클래스가 절대악이 아니라는 제 주장에 많은 크루들이 같은 의견을 표해 준 것 같아 나름 보람찬 발제가 아니었나 싶어요. |
Beta Was this translation helpful? Give feedback.
-
유틸성 객체의 기준은 무엇일까?
static은 나쁜가? Oop를 침해하는가?
주어진 2가지 상황의 코드를 보고 유틸 클래스의 기준을 공유해보자
Beta Was this translation helpful? Give feedback.
All reactions