사다리 미션에서 팩토리 패턴의 사용

LadderFactory를 사용했기 때문에 Ladder를 생성해주는 코드가 불필요하게 늘어난다는 것을 리뷰를 통해 알게 되었다. 리팩토링을 진행하며 LadderFactory 없이 new 생성자를 이용해 Ladder를 생성했더니 코드가 두 줄 정도 줄어들게 되었다. 알고 있던 팩토리 패턴의 사용법이 잘못되었다는 것을 인지하게 되었고, 팩토리 패턴의 정의, 활용성에 대해 공부하였다.

Ladder 미션에서 Ladder를 생성하는 로직은 LadderGame의 책임이 아니라고 생각해 LadderFactory를 통해 캡슐화하였다. Ladder를 생성하기 위해서는 Point 리스트를 생성해야 하고, Point 리스트를 Line 객체로 감싸야 하며, Line들의 리스트를 만들어 Ladder 객체로 감싸야 한다. 객체를 포장하는 책임은 LadderGame이 맡기에 불필요한 책임이라고 생각했다.

따라서 LadderFactory를 만들어 각 원시값을 객체로 포장하는 일을 맡도록 역할을 분리해주었다.

팩토리 패턴이란?

• 팩토리 패턴은 객체 생성의 책임을 팩토리에게 위임하는 것이다.
• 생성자를 직접적으로 사용하지 않기 때문에 클라이언트 코드와의 의존성이 낮아진다.
• 따라서 기존 코드를 변경하지 않고도 코드를 확장할 수 있다.
• new 생성자를 사용하여 객체를 생성한다면 객체명이 변경되거나 새로운 객체를 추가할 때마다 생성자를 변경해주어야 한다. 하지만 생성자 대신 Factory 패턴을 사용한다면 Factory 클래스 내부에서 생성자를 호출하는 부분만 변경해주면 된다. 이와 같은 점에서 생성자를 호출하는 클라이언트 코드와의 의존성이 낮아진다는 것이다.
• 팩토리 패턴에는 크게 Simple 팩토리 패턴, 팩토리 메서드 패턴, 추상 팩토리 패턴이 있다.

Simple 팩토리 패턴

• Simple Factory 패턴은 객체 생성의 책임이 Factory 패턴에 있는 것이다. input에 따라 다른 객체를 생성하게 되는데, input이 달라지더라도 Factory의 객체 생성 메서드만 수정해주면 되기 때문에 코드 확장에 용이하다.
• Simple 팩토리 패턴의 한계
  • 새로운 type이 추가될 수 있지만, 기존의 코드를 바꾸어야 한다.
  • 기존 코드를 바꾸는 것은 OCP원칙에 위배된다.
    • 확장에 용이하되, 기존 코드의 변경에는 닫혀있어야 한다.
• 위와 같은 한계로 인해 Simple 팩토리 패턴은 디자인 패턴으로 분류되지는 않는다.

팩토리 메서드 패턴

• 팩토리 메서드 패턴은 인터페이스 클래스를 갖고, 인터페이스의 구현 클래스에서 생성 메서드를 정의하게 된다.

예시

Phone

public interface Phone {

    void call();

}

iPhone