OOP : 객체지향

1. 시대가 OOP를 지나 단순하고 유연한 Data Oriented(DO)로 가는 시점이다. OO는 경직된 구조와 RDMS에 적합한 구조를 가지고 있다. 사실 예전에는 OO와 RDBMS가 맞지 않다는 생각에 OODB라는 개념까지 도입되었으나 현실적으로 잘맞는 쌍이다. 하지만 OO는 더 이상 NoSQL에 대응하기에는 너무나 경직되고 불편하다. Stream, Lambda, Reflextion, Custom Annotation 같은 새로운 개념이 자바에 도입되었지만 사실 Data Oriented 에는 잘 맞지 않다. 이런 개념이 로직을 작성을 편하게 하고 프레임워크를 개발하는데 더 큰 용도가 있긴 하지만 데이터의 구조와 데이터의 저장에도 많은 부분 영향을 미친다. 객체지향은 RDMS라는 공식은 변함이 없을 것 같다.

 

2. 쓸대없는 소리 말고 그냥 OOP의 수많은 원칙들과는 상관없는 것들이 생각나서 적어본다.

 

3. property, state 객체 지향에서 property는 말 그대로 클래스 속성이고 state는 이런 속성로 결정되는 객체의 상태이다.

  3-1 이게 중요한 이유는 현재 대세가 DO인데 DO의 핵심이 state와 immutable이다.

  3-2 이것은 동기화와 thread-safe와 연결되고 개발의 복잡성을 제거하는데 도움이 된다.

  3-3 객체의 상태라는 것이 아주 중요하다.

 

4. 객체 지향 설계 방법

  4-1 요구사항에 필요한 것들을 적는다. 즉 목적과 필요한 기능들을 주욱 적는다.

  4-2 필요한 클래스를 추출하여 설계한다.

  4-3 인스턴스 설계를 하여 어떻게 동작할지를 예측하고 Use Case를 통해 시나리오를 검증한다.

  4-4 Use Case는 검증은 이벤트 검증이다. 시스템은 무조건 Event를 통해 동작하기 때문이다.

    4-4-1 사용자의 interaction, job scheduler에 의한 동작, 시스템 연계 모듈의 호출 등을 생각하면 된다.

 

5. 이벤트 연동이 어떻게 객체 사이의 대화를 유발하고 처리되는지가 객체지향설계의 전부이다.

  5-1 UI 개발이 아닌 이상은 아주 명확한 경우를 제외하면 Composite 클래스 설계는 별로 좋지 않다.

    5-1-1 즉 하나의 객체가 다른 객체를 소유하는 방식은 유연성을 떨어 뜨린다.

  5-2 객체 사이의 연계는 직접적인 소유보다는 클라이언트 객체를 통해 주입하는 방식이 좋다.