백엔드 웹 개발에서 가장 대표적인 MVC 패턴을 제대로 이해하기 위해서는 먼저 소프트웨어 디자인 패턴에 대한 이해가 필요하다.
디자인 패턴은 처음에는 건축학적 관점에서 출발한 개념이었으나 1994년 GoF
의 Design Patterns: Elements of Reusable Object-Oriented Software
를 통해 소프트웨어 설계에서 공통적으로 발생하는 문제에 대한 재사용 가능한 솔루션으로 제시되었다.
물론 완벽한 설계는 없으며 시대의 흐름에 따라 달라질 수 있지만, 시행착오를 통해 스스로 터득해야 할 문제를 정리해둔 솔루션이 있다면 당연히 검토할 가치가 있는 것이다.
GoF의 디자인 패턴은 생성, 구조, 행동, 동시실행 등의 문제에 대해 여러 패턴을 제시하고 있으며 UML 클래스 다이어그램을 이용해 구조를 표현하고 있다.
UML이란 Unified Modeling Language
의 약어로 객체지향 설계와 구현을 지원하기 위해 만들어진 일종의 모델링 언어다. 프로그래밍 언어와 같은 형태는 아니고 시스템 분석, 설계에 필요한 내용을 여러 다이어그램 형태로 정의한 규격이다.
Factory는 '공장'이란 의미로 디자인 패턴에서 객체를 생성하는 역할을 의미한다. '추상적'이라는 의미를 가진 Abstract는 자바의 추상 클래스에서도 사용되는 표현으로 구체적인 내용의 구현을 하위 객체에 위임하는 모델이다. 따라서 추상 팩토리는 객체를 생성하는 것을 별도로 구현하되 관련된 구체적인 구현을 하위 클래스에서 담당하게 하는 설계 모델로 이해할 수 있다.
객체지향 프로그래밍은 클래스로부터 여러 객체를 생성하고 이들을 활용하는 구조이다. 따라서 프로그램에서 객체를 직접 생성하는 것이 당연하면서도 프로그램에 종속성을 만드는 요인이되기도 한다.
ProductDao productDao = new ProductDao();
dao.insert(data);
ProductDao Class
데이터베이스 연동을 구현한 클래스
insert() Method
파라메터로 전달받은 데이터를 데이터베이스에 저장하는 메서드
위 코드는 문제가 없어 보이지만 ProductDao라는 클래스에 대한 종속성을 만들게 된다.
예를 들어 현재 시스템에서 오라클 데이터베이스를 사용하고, ProductDao 클래스 역시 오라클에 맞게 제작된 클래스라 가정하자. 이 경우 데이터베이스를 MySQL 또는 다른 데이터베이스로 교체할 경우 ProductDao를 MySQL에 맞게 다시 구현해야 한다.
그런데 상황에 맞게 오라클 혹은 MySQL에서 실행되어야 한다면 현재 프로그램의 전반적인 구조를 수정할 수밖에 없을 것이다. 추상 팩토리 패턴은 이러한 경우 유용하게 사용할 수 있다. 직접적인 객체 생성 대신 팩토리 클래스에 객체 생성을 위임하는 구조이기 때문이다.
다음 코드는 패턴 구조를 적용한 경우 클라이언트에서 팩토리를 사용하는 부분만 예로 든 것이다. 패턴 적용에 대한 이해를 돕기 위한 것으로 전체 패턴을 구현한 것이 아니다.
ProductDao productDao = new ProductDao("oracle");
dao.insert(data);
ProductDao Class
추상 클래스 또는 인터페이스이다. ProductDao 추상 클래스를 상속받는 OracleDao, MySQLDao 등의 클래스가 존재한다.
DAOFactory
오라클이나 MySQL용으로 구현된 ProductDao 타입의 객체를 생성해서 리턴한다.
위의 예시와 같이 생성자의 파라메터로 특정 인스턴스를 요청할 수도 있고 .xml 설정 파일 등을 이용해 코드 수정 없이 확장 가능한 구조도 가능하다.
최근에는 개발자가 직접 애플리케이션 실행을 위한 모든 환경을 설계하고 개발하는 형태가 아니라 프레임워크, 컨테이너 기반으로 개발하기 때문에 직접적인 패턴 구현에 대한 고민은 줄어들었다. 하지만 소프트웨어 설계에서 디자인 패턴은 여전히 중요한 개념이다.