Factory

• 같은 개념을 공유하는 다양한 object들이 각기 다른 환경에서, 다른 작업을 하는 경우는 꽤 흔하다. 예를들어 배랑 차는 둘 다 '운송'을 할 수 있지만, 어디서 어떻게 운송을 하는지는 다 다르다.

• 이를 각 class에 대해 일일이 구현하는 것은 프로그램을 매우 복잡하게 할 위험이 있다. 물론 차랑 배가 둘 다 같은 method를 가지도록 복사 붙여넣기(...)를 해도 되기야 하겠지만 둘의 관계가 아무것도 지정이 안되어 있는것은 물론 추후 다른 운송수단이 추가될 경우 (비행기) 이를 확장하는데도 시간이 좀 오래 걸리게 된다.

• 따라서 그 '개념' (위의 경우 '운송')을 가지는 다양한 object를 만드는 인터페이스를 형성하는게 바로 factory design이다. 거기서 생성 method를 정의하고, 이를 하위 class들 (위의 경우 배랑 차)이 세부적으로 implement를 해서 프로그램의 복잡도를 줄이는 것이다.

• 그리고 위의 '개념'을 가지는 object를 다룰 때는 그 녀석의 세부 class가 뭔지 상관없이 '개념'에서 지원하는 action들을 수행하면 하위 class에 맞게 알아서 실행되도록 하는 것이다. 즉 object가 무엇인지 구체적으로 신경쓰지 않으면서 목적에만 집중을 하는 것이 가능한 디자인 방식이다.

• 대표적인 장점들로는

  • 코드를 사용하는 부분과 객체를 생성하는 부분이 분리가 되어서 특정 개념에 대응되는 새로운 object부류를 기존 코드에 문제를 일으키지 않으면서 쉽게 추가 할 수 있다는 점.
  • 이미 만든 object를 재활용해서 구현하는게 가능하다는 점
  • 해당 개념에서 새로운 method가 추가가되거나 삭제가 되었을 때 이를 편하게 관리할 수 있다는 점. (사실 이건 인터페이스의 장점 느낌이 크다.)
  • 외부 사용자가 특정 개념에 해당하는 신규 object class를 추가하는 것은 물론, 이것을 해당 프로그램에서 활용할 수 있도록 확장하는것을 금방하게 할 수 있다는 점.

• 관련 유용한 글! 직접 구현하는 방법도 내포하고 있다.

• Spring/Spring Boot의 경우 Bean Factory가 여기에 해당된다.

Repository

• 간단하게 말해, 데이터 취급 과정을 간단하게 해주는 class다.

• 보통 data에 접근하려는 application과 현재 운용중인 DB에서 제공하는 직접적인 API들 사이에 위치한다.

• 이를 통해 application에서의 business logic과 data retrieval process를 분리해서 application designer이 좀 더 business logic에만 집중하는 것을 가능하게 해준다.

• 관련 유용한 글!

• Spring/Spring Boot의 경우 CrudRepository나 JPARepository가 여기에 해당된다.