인스턴스 생성할때 어떻게 할까? --------> new MyClass(); 만약 생성자가 private으로 선언돼있으면? --------> 인스턴스 생성 불가. 생성하게 하려면?? --> 인스턴스변수를 static변수로 미리 선언후 --> 요청시 인스턴스 변수를 만들어서 넘겨주는 식으로 생성해준다. public class Singleton{ private static Singleton uniqueInstance; private Singleton() { } // private로 선언된 생성자 public static Singleton getInstance() { //인스턴스 생성하는 메소드 if (uniqueInstance == null) { //인스턴스가 생성된 적이 있는지 확인후 uniqueInsta..
"new" 는 구상 객체를 뜻한다. 앞에서 배운 것 처럼 구상클래스를 바탕으로 코딩하면 나중에 코드를 수정해야 할 가능성이 높아지고, 유연성이 떨어지게 된다. Duck duck; if( picnic) { duck = new MallardDuck(); } else if( hunting ){ duck = new DecoyDuck(); } else if ( inBathTub){ duck = new RubberDuck(); } 이런 코드는 뭔가를 반영하거나, 확장해야 할때 코드를 다시 확인하고 추가 또는 제거 해야 한다는 것을 뜻한다. 따라서 이런 코드는 관리 및 갱신이 힘들어지고 오류가 생길 가능성이 크다. 애플리케이션에서 구상클래스의 인스턴스를 만드는 부분을 아예 다른쪽으로 분리 시켜야 한다. 앞에서 배웠던..
커피 전문점을 생각해보자. 객체 마을에 스타버즈라는 커피숍이 있다. 커피의 종류는 여러가지에 추가할수 있는 메뉴가 수십가지가 될수도 있다. 다음 그림을 보자. 이렇게 클래스 개수가 엄청나게 늘어난다. 커피 메뉴가 더 늘어나면 훨씬 더 늘어날 것이다. 상속이 강력하긴 하지만, 모든 서브 클래스에서는 똑같은 행동을 상속받게 된다. 이럴때, 구성을 통해서 행동을 확장하게 되면 실행중에 동적으로 행동을 설정할 수있다. (스트레티지 패턴) 디자인 원칙 ) 클래스는 확장에 대해서는 열려있어야 하지만, 코드 변경에 대해서는 닫혀 있어야 한다. O.C.P ( Open-Closed Principle) *무조건 OCP를 적용하는 것은 시간 낭비가 될수도 있다. 코드를 확장해야 할 부분을 선택할때는 세심한 주의를 기울여야 ..
* 옵저버 패턴은 쉽게 말해서, 신문사 구독 메커니즘과 같다고 할수 있다. 출판사를 주제(Subject) , 구독자를 옵저버(Observer) 라고 정해보자. 옵저버는 등록(register) , 제거(remove) 가 자유롭다. 옵저버 패턴 정의 ) 한 객체의 상태가 바뀌면 그 객체의 의존하는 다른 객체들한테 연락이 가고, 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의한다. 옵저버에 대한 모든 제어 ( 등록(register) , 제거(remove) , 알림(notify) ) 는 Subject에서 관리한다. 디자인 원칙 ) 서로 상호작용을 하는 객체 사이에서는 가능하면 *느슨하게 결합하는 디자인을 사용해야한다. * 변경사항이 생겨도 쉽게 처리를 할수가 있다. 객체 사이의 상호의존성을 최소화 할수 ..
* 상속을 잘 활용하면 재사용 할수 있지만, 실제 코드를 정비 하는데는 별 도움이 되지 않는다. 이런 식으로 코드를 구현하면 , 나중에 행동을 추가한다던지, 다른 오리를 추가 할때 문제가 발생한다. 코드를 재사용하는 점에서도 좋지 않고, 나중에 날아다니는, 꽥꽥 거리는 행동을 바꿀때, 모든 코드를 다 바꿔야하는 상황을 초래한다. 디자인 원칙 ) 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다. 그렇다면, Duck클래스에서는 ? 나는 행동과 꽥꽥 거리는 행동을 분리 시킨다. 디자인 원칙 ) 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다. 이런식으로 디자인 하면 다른 형식 개체에서도 나는 행동과 꽥꽥 행동을 재사용 할수 있다. (코드의 재사용) 그리고, 기존의 행동 클래스를..
