private final이 묵시적으로 선언된다. 좋아보이긴 한데, VO보다는 오히려 엔티티같은 객체에 좀 더 어울리는 것이 아닌가? 하는 생각도 들었다. 그리고 모든 것을 빼도 제대로 동작하게 만들도록 하는 방어적 코드 관점에서는 별로인게 아닌가 싶다. Autowired를 지양하는 것 처럼.오늘 히로랑 객체지향에 관한 얘기를 했다. 이후에 해본 생각들이다.
뷰에 보내주는 DTO와 DB에 보내줄 DTO에 관한 얘기였다. 이런 객체들은 사실 객체가 아니라 자료 구조(data structure)에 가깝다는 것. class라 생각하면 struct라고 생각해볼 수 있겠다. DTO와 엔티티는 양 끝에 있는 스냅샷이다. 가운데에서 객체가 활동하다가 특정 시점의 상태를 자료구조로 변환하여 보내준다.
그런 관점에서 보면 ORM의 의미를 보다 명확하게 알 수 있다. 엄밀히 말하면 ORM은 entiy(비즈니스 데이터)와 db 테이블을 매핑하는 것이기 때문에 객체 관게 매퍼가 아니다. 그럼에도 ORM이라 부르는 이유는 프레임워크 단에서 객체지향적인 설계를 강제해주기 때문이다. ORM은 자료구조와 테이블을 매핑해주지만, 객체지향 적인 설계를 했기 때문에 매핑의 결과로 나오는 자료구조를 객체처럼 사용할 수 있다. 반면, 스프링에는 객체지향적인 요소가 많이 들어있음에도 웹 아키텍쳐에서 사용되는 MVC의 흐름이 절차적이기 때문에 문제가 발생할 수 있다. 물론 MVC가 객체지향적이지 않다는 논거 중에 양 극단에 객체가 아닌 자료 구조가 사용되기 때문이라는 것이 가장 주요하지만, 이외에도 웹 아키텍쳐의 흐름은 절차적일 수 밖에 없다. 잘 생각해보면 이는 어쩔 수 없는 부분이다. switch문을 아무리 제거하려 해봐도 완전히 제거하는 것은 불가능한 것 처럼, 절차적인 흐름을 어디에선가는 가져가야 한다. 아무리 캡슐화시킨다 한들, 그 것은 관점의 차이일 뿐이기 때문이다. 따라서 절차적인 부분과 객체의 세계를 구현할 부분을 잘 나눠서 격리시켜야 한다. 서로 오염되지 않도록.
MVC의 장점은 각 레이어를 고립시켜서 개발한다면 양 극단에 있는 객체지향적이지 않은 부분을 배제하고 핵심적인 부분에서 객체를 이용해 구현할 수 있다는 점이다. 하지만 이를 강제하기 전까지는 단순한 패턴에 불과하다. 스프링 MVC에서도 마찬가지로 각 영역을 구분지어주는 강제성이 없다. 이 때문에 필요에 따라 서비스를 생략하거나 각 레이어의 인터페이스를 생략하는 등의 융통성 있는 개발이 가능하지만, 반면 제대로 이해하지 못 하고 사용한다면 절차적인 코드가 나올 수 밖에 없다. 흔히 가장 많이 하는 실수인 서비스 메소드를 c의 main 메소드 처럼 사용하는 것이다. 이런 경우 각 도메인 객체는 자료구조로 전락한다. 이 것이 문제다.
알고리즘
Powered with by Gatsby 2.0