새로운 시작

유틸리티 클래스를 설계하면서의 고민..
1. 네이밍
2. 구조
3. as-is와의 호환?

유틸리티 클래스에 대해서는 설계적인 고민을 전혀 하지 않았다. 어차피 static메소드 자체가 OO와는 거리가 있다는 생각에 그냥 필요한 메소드를 쭉 구현만하면 되지 않을까라는 생각을 가지고 있었다. 이런식의 생각은 매우 위험하다. 특히 어차피 라는 말.. 어차피가 들어가기 시작하면 설계고 구현이고 대충 하게 되도 어차피라는 말로 전부 커버가 되버린다. 비록 static 메소드만을 가지고 있는 유틸리티 클래스 일지라도 그 범위내에서 고민할 내용들은 무지 많아진다 특히 프레임웍 개발이나 공통 패키지의 작업일 경우는 더욱 그러하다.

네이밍이 엉망일 경우 나같아도 그기능을 사용하지 않는다. 네이밍을 보고 일단 무시 들어가 버린다. 근데 내가 그렇게 무시당하도록 아무생각없이 그냥 만들어 버렸다. 쪽팔린다.

같은 기능을 하는데 아규먼트의 종류나 수가 다를경우 어떻게 설계해야 하는가.. 이때는 두가지 방법이 가능할 것 같다. 메소드의 오버로딩이나 아니면 그냥 메소드를 분리하는거다. 난 후자를 택했다. 이유는 어차피 때문이다.. 어차피 스태틱 메소드인걸.. 그런생각에

나는 항상 어떤 한계를 가지고 뭔가를 생각하는 것 같다 as-is를 분석하면 그 sa-is를 마치 지켜야 하는 성역인것 처럼 생각하게 된다. as-is에서 잘못된 것을 바로 잡는것이 to-be의 목적중 하나일텐데.. 잘못된것은 과감하게 잘라버리자. as-is의 한계속에서 나아가 기술적인 한계속에서 생각하지 말자