우테코에서 사다리 미션을 구현하다가 피드백을 받은 내용이다.
메소드를 분리하다가 모든 클래스에서 재사용할 수 있도록 static method로 구성하면 안될까? 라는 생각을 했다.
당시에는 단순히 한번만 생성되고 재사용할 수 있는 메소드라고 여겨졌고, 코드를 축약할 수도 있다는 부분이 장점이라고 생각해 static method를 사용했다.
static method를 사용했을 때 장, 단점에 대해 생각해보자.
위 서론에서 생각했듯이 메소드의 반복적인 사용에 매우 용이하다.
명시적인 Performence를 측정하지는 못하지만 인스턴스의 생성과정이 생략되기에 동일한 기능을하는 static 메소드와 non-static 메소드를 비교한다면 static 메소드의 속도가 더 빠를 것이라고 유추할 수 있다.
그렇다면 모든 method를 static으로 바꾸면 좋은게 아닐까?
속도도 빠르고, 어디에서나 재사용 가능하고... 사실 static method는 만능이 아닐까? 안 쓸 이유가 없나?
위 마지막 문장을 보고 고개를 끄덕였다면 이 단점을 반드시 생각해볼 필요가 있다.
우리는 객체지향을 기반으로 둔 자바를 사용하고있다.
우테코 레벨인터뷰를 하면서 static method를 사용하면 객체지향에서 멀어진다는 의심을 해볼 필요가 있다.
라는 피드백을 들었다.
가만히 생각해보면 맞는 말이다.
static method를 보면 어떤 객체가 스스로 동작하는것이 아닌 Util 느낌의 클래스에서 메소드를 뽑아서 사용하게 된다.
이러한 방식으로 모든 코드를 작성한다고 생각해보면 절차지향에 가까워지는 모습을 생각해 볼 수 있다.
객체간의 메시지로 소통하는 것이 아닌 전역 함수로 절차를 이어나가는 모습에서부터 객체지향과 멀어지고 있음을 알 수 있다.
객체지향의 특징도 지키기 어려운 모습을 볼 수도 있다.
static 메소드에 대해 추상화, 상속, 다형성, 캡슐화 무엇 하나라도 적용할 수 있는가?
컴파일 타임에서 정적 바인딩이 되는 static 메소드에 대해 위와 같은 내용들이 적용될 수 있는가?
static 메소드는 객체지향의 입장에서는 달갑지 않은 형태라고 볼 수 있다.
과도한 사용은 지양해야하며 사용 시 몇가지 기준을 세우면 좋을 것 같다.
일단은 위와 같은 기준들이 생각난다.
위 기준은 주관적인 기준이고 각자의 주관에 맞춰 생각해보면 좋을 것 같다.
메모리의 관점에서 생각해봤을 때? 라는 말이 간혹 나오기도 한다.
static으로 생성되면 프로그램이 종료될 때 까지 메모리를 점유하고있고,
메모리를 점유하고 있는 static 메소드 혹은 변수들이 많아졌을 때 메모리에 어떤 부하가 올 수도 있다?
static 메소드는 GC의 대상이 아니고... 이로인해 점유중인 메모리가 많아지면 성능이 저하된다..?
아직 해당 부분에 대한 지식이 없기 때문에 섣불리 메모리관점에 대한 의견을 제시하기는 어렵다.
대신 고민해볼 만한 키워드를 얻어간다.
https://www.mimul.com/blog/oop-alternative-to-utility-classes/ 처럼 유틸리티 클래스들을 객체로 뺄 수도 있습니다!
개인적으로 메모리 문제는 고려할 필요가 없다고 생각하는 편입니다. 보통 메모리 문제는 힙에서 터지는 경우가 많기에... 오히려 메모리 아끼려고 static으로 쓰는 경우도 있죠