꼰대 개발자~

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

C++ 부터 java를 거치면서 수 많은 시행 착오를 거치면서 나름데로 OOP 설계/구현 원칙을 강요(?)해왔다. 이런 설계 원칙을 누군가 외쿡사람이 정의해 해왔네 이걸 실무적으로 얘기해 보고자 한다.

• S - Single-Responsiblity Principle (SRP)
  • 하나의 클래스는 하나의 일만 해야한다는 얘긴데...
  • 이건 실무적으로도 중요한 개념이다.
  • 하나의 기능에 관한 data / method / error등을 모아 둠으로써 변경에 대한 응집성을 높여서 변경에 대한 실수를 줄이고 코드에 대한 가독성 또한 높여준다.
  • 필수사항
• O - Open-Closed Principle (OCP)
  • OOP의 지향점인 추상화와 다형성에 대한 원칙
  • 쉽게 확장가능해야하고 변경발생시 다른 확장들이 영향이 미치면 안된다? 요렇게 정의해 볼까한다.
  • 간단히 얘기하면 if{ } else if{ }  else if{ } else {} 이런거 하지 말라는 말이다.
  • 요건 좀 아키텍트로서는 고민되는 부분이다. 대부분의 도메인들이 extend할수있을 만큼 constant하지 않기 때문이다.
  • 동적 데이터에 대한 switch, if-else pattern을 벗어 나려면 "Adapter pattern"을 통해서 OCP 부족한 점을 채울 수 있을듯...
  • 어찌되었던 디자인 패턴이니까 최대한 OOP의 다형성을 활용하자
• L - Liskov Substitution Principle (LSP)
  • sub class는 base class로 언제든 변환될 수 있어야 한다는 얘긴데...
  • 대부분의 언어들이 제공하는 casting을 통해서 sub class의 type을 몰라도 base class의 public property나 method에 접근가능해야한다는 얘긴데.....
  • java같은 signature가 있는 언어는 간단한데 C++같은건 조금 커스텀한 테크닉이 필요하다. 기본적으로 heap를 사용해야해서 C++같은 언어에서는 조금 유연하게 적용해도 될듯하다.
• I - Interface Segregation Principle (ISP)
  • interface의 구현도 통합하지 말고 기능별로 분리해라 라는 얘기입니다.
  • 최신의 신규 언어들도 언어적으로 지향하는 원칙으로 지키는것이 좋습니다.
  • 너무 많이 나누면 interface관리 자체가 burden이 될것입니다. 
  • 기능을 잘 분리하여 적절히 나눕니다.
  • scale / rust는 이런 이유로 interface를 trait 이라는 특성으로 분리 합니다.
• D - Dependency Inversion Principle (DIP)
  • 이것 역시도 상속을 통한 Event 수신을 하던 아주 오래된 패턴이다.
  • 공통로직을 base class에 담고 하위 class의 method을 참조할 필요가 있을때 추상화된 overriable method을 사용하여 하위 class에 종속된 기능을 추상화 하자는 얘기다.
  • 일반적으로 사용하는 callback, handler등이 이것에 해당된다.
  • 공통로직을 base class에 모아두고 sub class 특성을 담은 method만 추상화하여 로직의 통합한경우 즉 abstract class pattern들이 여기에 해당된다.