전략 패턴과 비슷한 개념인데 거기서 조금 더 생각한 패턴이다.
객체를 생성하는 코드를 한 객체 또는 메소드에 집어넣으면 코드에서 중복되는 내용을 ㅈ ㅔ거할 수 있고
나중에 관리할 때도 한 군데에만 신경을 쓰면 된다.
클라이언트 입자에서는 객체 인스턴스를 만들 때 구상 클래스가 아닌 인터페이스만 필요로 하게 된다. 이렇게 하면 구현이 아닌 인터페이스 바탕으로 프로그래밍을 할 수 있게 되고 유연성과 확장성이 뛰어나진다.
진짜 객체의 인스턴스를 만들 때는 여전히 구상 클래스를 사용해야 하는데 이것은 어쩔 수 없는 것이다.
하지만 이것을 이해하고 생성코드를 한 곳에 모아노고 체계적인 관리를 할 수 있는 설계를 한다면 관리하기 편리해진다. 객체 생성 코드를 아무곳에나 두면 결과를 얻기가 힘들어진다.
서브 클래스를 사용하고 최대한 new를 사용하지 않는다.
new를 사용하는 것이 구상 클래스를 호출하는 것이 된다.
객체 의존성>>
객체 인스턴스를 직접 만들면 구상 클래스에 의존해야 한다.
구상클래스에 의존하지 말고 추상화된 것에 의존하도록 한다.
객체를 생성하는 코드를 한 객체 또는 메소드에 집어넣으면 코드에서 중복되는 내용을 ㅈ ㅔ거할 수 있고
나중에 관리할 때도 한 군데에만 신경을 쓰면 된다.
클라이언트 입자에서는 객체 인스턴스를 만들 때 구상 클래스가 아닌 인터페이스만 필요로 하게 된다. 이렇게 하면 구현이 아닌 인터페이스 바탕으로 프로그래밍을 할 수 있게 되고 유연성과 확장성이 뛰어나진다.
진짜 객체의 인스턴스를 만들 때는 여전히 구상 클래스를 사용해야 하는데 이것은 어쩔 수 없는 것이다.
하지만 이것을 이해하고 생성코드를 한 곳에 모아노고 체계적인 관리를 할 수 있는 설계를 한다면 관리하기 편리해진다. 객체 생성 코드를 아무곳에나 두면 결과를 얻기가 힘들어진다.
서브 클래스를 사용하고 최대한 new를 사용하지 않는다.
new를 사용하는 것이 구상 클래스를 호출하는 것이 된다.
객체 의존성>>
객체 인스턴스를 직접 만들면 구상 클래스에 의존해야 한다.
구상클래스에 의존하지 말고 추상화된 것에 의존하도록 한다.