밤에 쓴 코드

SOLID - 객체 지향 5 원칙 나쁜설계는 변경에 취약한 소프트웨어를 만든다 나쁜소프트웨어는 디른 곳에 영향을 주어서 A기능 수정이 B기능까지 영향을 주어 , 갑자기 엉뚱한 곳이 망가질 수있고 , 그에 따른 연쇄되는 수정이 동반되어야 할것이다. 또 서로 연관 없는 코드들이 결합되어 있기 떄문에 , 하나를 재사용하려고 해도 , 그에 관련된 코드들을 줄줄이 사용하지 않으면 시스템에 문제가 생길 것이다. 또 한 곳에서 동작이 이리저리 퍼지고 , 또 한곳에서 여러동작을 하게 되면 메소드의 이름도 모호해지고 , 하는 일도 명확해지지 않게 될 것이다. 이런 코드를 스파게티 코드 라고 부른다 . 이리저리 서로 얽히고 설켜서 , 끔찍한 코드를 보게 될 것이다 . 이 문제를 해결하기위한 많은 무기들이 있다 . 인터페이..

옵저버 패턴 한 객체가 바뀌면 그 객체에 의존하는 다수의 객체들한테 연락을 보내고, 갱신되는 방식으로 일대다 의존성을 정의한다. 시계를 예로 들어보자. 시계들은 시간이라는 큰 개념에 의존하고 있다. 시간이 바뀌면 시계들은 내부의 상태를 변경해야하는 의무가 있다. 어떻게 표현하는게 좋을까? 알려주기 시간은 계속적으로 바뀔 것이고 , 시간을 담고 있는 Time 객체는 그에 따른 변화가 있을 것이다. Time 객체가 자기 자신이 바뀌었을 때, 모든 시계들에게 바뀌었다는 사실과 데이터를 알려주면 되겠다. 1.시간이 바뀌었을 때 시간값을 바꿔야하는 시계객체 2.날씨가 바뀌었을 때 날씨값를 바꿔야하는 기상정보어플객체 3.날짜가 바뀌었을 때 날짜값를 바뀌어야하는 달력객체 은 어떤 공통점이 있을까? 위의 3가지 객체의..

Factory - 팩토리 구체적이면 구체적일 수록 변화에 취약하다. 인스턴스를 생성하는 코드는 되게 구체적인 부분이라 유연하지 않다. 그 부분을 분리하기 하여 관리하려는 노력에서 나온 패턴이다. 변화에 취약한 부분을 분리하자 구체적이면 구체적인 부분일수록 변화에 취약하다. 특정 구상 클래스의 인스턴스를 생성하는 부분은 굉장히 구체적인 부분이므로 , 분리해서 관리하는 것이 좋다. 구체적인 클래스에 직접적으로 접근하는 것은 팩토리 만으로 한정 짓는다. 생성할 객체를 추상화하자 팩토리메소드는 구상클래스의 인스턴스를 반환한다 . 하지만 생성된 인스턴스를 받을 구체적인 타입을 알지 못한다. 좀더 세분화하여 구체적인 객체를 생성해야 한다면 생성 자체를 추상화하자 객체를 생성함에 있어서 단계를 나눌 수 있다. *게임..

스트래티지 패턴 스트래티지 패턴에서는 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다. 문제점 상속 일부 적합하지 않은 서브클래스가 존재할 수 있다. 인터페이스 인터페이스를 채택한 클래스에서 구현이 이루어진다. 코드의 중복이 야기된다. 디자인 원칙 달라지는 부분과 달라지지 않는 부분을 분리 - 달라지는 부분 캡슐화 인터페이스(상위형식)에 맞추어 프로그래밍 상속보다는 구성(Composition) 개발기간보다 개발이 끝난 후에 코드에 더 많은 시간을 쓴다. 재사용성도 중요하지만 확장성,관리의 용이성이 더 중요하다. 동작이 유연하게 관리되어야 하는 설계에서는 스트래티지 패턴은 좋은 선택이..

디자인패턴 기존 환경내에서 반복적으로 일어나는 문제들을 설명한 후 그 문제들에 대한 해법의 핵심을 설명 , 재사용 할수 있게 하는 패턴 기대효과 공통적인 설계자들의 어휘의 수준을 높여준다. 논의에 있어서 대화의 많은 영역을 추상화하여 더 간결하게 표현할 수 있어서 , 더욱 지적 대화가 가능하다. 적은 단어로 많은 내용을 내포하여 의도를 제대로 전달 할 수 있다. 디자인패턴을 인용한 대화 - 객체의 이동하는 동작에 대해서는 스트래티지패턴이 적절하겠네요. 객체의 이동을 표현하기 위해서는 이동하는 동작을 정의한 인터페이스를 정의하고 , 해당 인터페이스를 구체화한 클래스를 추상화되어있는 인터페이스에 합성시키고 인터페이스에 정의된 메소드외에는 은닉하고, 동적으로 수정할 수 있게 프로그래밍하면 적절하겠네요. 시스템..