디자인패턴

코드를 짜다보면 클래스 인스턴스가 프로젝트에서 단 한번만 생성되기를 바랄 때가 있다.다음예제는 text 파일을 출력하는 TextController라는 싱글 인스턴스가 있고 해당 인스턴스가 가지고 있는 자료구조(queue)에 멀티 쓰레드 환경(Parallel)에서 아이

비용이 적게 드는 방향으로 빠르게 개발하게 되면 효율적으로 코드를 짜기 어렵다내 개발 비용과 컴퓨터의 비용은 반비례하는 것 같다. 알고리즘이 그렇다.어떠한 목록(list)에서 연산을 하는 함수를 만든다고 가정할 때 내 개발 비용이 적게 들기 위해 최악의 알고리즘으로 짜

'어떠한 행위' 앞, 뒤 혹은 중간중간에 반복적으로 수행하는 코드들이 존재한다. 그 코드들을 일반화한다. 부모클래스에서 반복적으로 하는 일들을 정의하고 파생클래스에서 '어떠한 행위'를 정의하는 것을 약속한다. 주로 라이브러리를 만들 때 자주 사용하는 패턴이다.

코드를 작성하다보면 일반화된 클래스의 인스턴스들의 관리가 필요할 때가 있다. 일반화된 클래스의 추가, 수정 등에 개발 리소스를 줄이고 인스턴스의 생성을 보장해줄 때 쓰인다.어떠한 행위를 하는 객체를 일반화하기 위해 인터페이스를 정의한다. 정의된 인터페이스를 만들기로 약

코드를 짜다보면 객체의 상태를 변경할 때 의존성이 있는 객체들의 상태들 까지 변경되길 바랄 때가 있다. 대부분 그렇지 않겠지만 코드를 중복해서 짜는 경우가 있다면 옵저버 패턴을 이용하면 꽤 괜찮은 코드를 짤 수 있다.다음 예제는 직원(Employee) 객체는 평가(Ra

우리가 코드를 짜다보면 의도치 않게 많은 파생클래스를 만들어 낼 때가 있다. 정말 필요한 파생클래스 일 수도 있지만 그 모델의 디자인을 다시한번 살펴 볼 필요가 있다. 파생된 클래스에서 정의되고 있는게 다른 파생클래스에서도 정의하고있는 반복적인건 아닌지를 말이다. 이때