본문 바로가기

DesignPatterns

Design Patterns http://www.dofactory.com/Patterns/Patterns.aspx Design Patterns Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges. The Gang of Fou.. 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (8) Singleton 패턴 아마도 가장 유용하다고 가장 단순한 디자인 패턴 중의 하나가 Singleton 패턴이다. 이 패턴의 목적은 프로그램의 실행 시간 동안에 한 오브젝트의 인스턴스가 만들어졌는지 확인하는 것이다. Singleton 패턴의 일반적인 구현은 다른 클래스들이 접근할 수 없는 private 생성자와 public 메소드를 만드는 것이다. 이때, 메소드는 자신이 호출될 때 존재하는 인스턴스가 없으면 만들고, 있다면 기존의 인스턴스가 가지고 있던 작업을 가지고 있는 생성자와 비슷한 영할을 한다. Singleton과 멀티스레딩 Singleton 패턴의 구현은 멀티스레딩 프로그램에서 약간의 트릭을 얻을 수 있다. 그래서, 프로그래머들은 Singleton 패턴을 다시 구현하기보다는 잘 테스트된 코드를 종.. 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (7) Chain-of-Command 패턴 이 패턴은 명령 오브젝트들과 처리 오브젝트들을 별도로 분리할 수 있고, 연속된 처리를 해야 하는 상황에서 이를 실행되는 장소와 기능 모두를 가질 수 있는 오브젝트를 만들 수 있도록 해주는 매우 강력한 디자인 패턴이다. 그래서, 워크플로우나 연속적으로 발생하는 상황을 구현하는 데 매우 유용하다. 하지만, Chain-of-Command 패턴은 주의 깊게 사용해야 한다. 왜냐하면, 절차적인 프로그래밍을 하다가 객체지향 프로그래밍으로 갈아타는 개발자들은 단 하나의 명령 오브젝트와 수없이 많은 처리 오브젝트들을 만들어 낸다. 이러한 부분들은 객체지향 방식을 사용으로 바꿔야 할 곳인데 습관적으로 반복되는 불필요한 절차적인 코딩을 계속 반복하게 될 경우가 많다 각각의 처리 오브젝트.. 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (6) Factory Method 패턴 Factory Method 패턴은 디자인 타임보다는 런타임 시에 오브젝트의 클래스를 명시하면서, 오브젝트의 생성을 추상화할 수 있게 해준다 오브젝트를 생성하는 별도의 메소드를 별도의 정의를 통해서 추상화를 구현한다. 하위 클래스들은 필요할때마다 생성하게 되는 파생 오브젝트의 타입을 별도로 명시하기 위해서 클래스를 생성하는 메소드를 재정의할 수 있다(필요할 때마다 필요한 것을 생성한다는 의미로 받아들일 수도 있다) 사실 factory라는 단어는 오브젝트의 생성을 주목적으로 하는 임의의 매소드를 참조하기 위해 사용된다 Factory 메소드들은 툴킷이나 프레임워크 같은 곳에서 매우 많이 볼 수 있다. 이러한 곳에서는 많은 라이브러리들이 있게 마련이고, 이 코드들은 프레임워크를 .. 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (5) 닷넷 3.5를 이용한 디자인 패턴의 구현 (4) 에서본 Observer 패턴을 다시한번 더 본다 새롭고 세련된 윈도우 형식의 세상에서 우리는 종종 동시에 한 가지 이상의 형식으로 데이터를 표현하고자 하고, 그 데이터에 발생한 모든 변경사항도 한 번에 나타내기를 원한다. 예를 들어, 증권시세의 변화를 그래프와도표 또는 목록 상자로 표시할 수 있다. 시세가 변할 떄마다 우리가 수동으로 별다른 조치를 취하지 않고도 한 번에 모든 수치가 변하기를 바라기도 한다. 이러한 종류의 행위가 이루어지길 바라는 것은 우리가 그동안 엑셀과 같은 수 많은 윈도우 애플리케이션에서 이런 일들이 이루어지고 있는 것을 보았기 때문이다. 윈도우에는 이러한 행위를 허용해주는 상속성이 없으며, 여러분도 알다시피 C/C++로 윈도우에 직접.. 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (4) 이름에 짐작할 수 있듯이, Observer 패턴은 오브젝트의 상태를 관찰하는 데 사용된다. 이 패턴이 약간 변형된 패턴이 출판 (Publish)과 구독(Subscribe)이다 관찰 대상 오브젝트는 어떤 이벤트 혹은 이벤트들을 "출판"하고 이들을 주시하고 있던 오브젝트들(관찰자들)은 발생한 이벤트를 "구독"한다. 이것을 좀 더 단순화하기 위해, 두 패턴을 모두 Observer 패턴이라고 부를 것이다. 사실 이 두 가지 패턴의 차이는 보는 관찰 시점의 차이일 뿐이다. 쉽게 얘기해서, '당신이 나를 관찰하고 있나요? 와 내가 당신이 구독하려는 나의 이벤트를 출판하고 있나요? 의 차이와 같다. 전자는 나를 보는 관점이 타인이 시점이고 후자는 자신의 시점에서 일어나는 이벤트를 관찰하게 된다. Observer 패턴.. 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (3) 3.5 SP1 기준 MVC 다운 HTTP://ASP.NET/MVC ASP.NET MVC Framework 3.5 버전의 일부를 포함한 대부분의 닷넷 버전에서는 컨트롤로의 역할이 이벤트 치리기, 프레임워크, CLR,운영체제등으로 분산되어 있기때문에 MVC패턴을 쉽게 개발하지 못한다. 대신, 마이크로소프트는 n-티어 개발 방식을 강조했고 모델의 역할을 비즈니스 오브젝트와 데이터 오브젝트로 더 명확히 구분한다. 데이터 오브젝트는 많이 사용하는 ADO.NET클래스 라이브러리나 Entity Framework같은 형태로 제공된다 하지만 마이크로소프트는 ASP.NET를 위한 MVC Framework를 제공한다. 이 프레임워크는 닷넷 프레임워크에 MVC디자인 패턴을 매핑시켜 강력한 시너지 효과를 만들어 준다. ASP... 더보기
닷넷 3.5를 이용한 디자인 패턴의 구현 (2) N-티어 패턴 마이크로소프트는 매우 긴 시간 동안 n-티어 개발에 전념했다. 그것은 1999년에 소개되어 핸져는 거의 사양화된 DNA(Distributed interNet Architechture)의 핵심이었고, 현재는 닷넷의 핵심으로 남아있다 이전에는 N-티어라고 하면 "3계층 혹은 그 이상"을 의미했다. 필수적으로 요구되는 3계층은 UI를 담장하는 프리젠데이션, 비즈니스로직, 데이터계층이었다 물론, 3계층보다 더 많은 것도 가능하다 . 예를 들어, 일부 개발자들은 로직처리를 담당하는 비즈니스 계층을 업무흐름(workflow)과 규칙(rule)으로 분리하기도 하고, 데이터 계층을 프로그램에서 처리할 부분과 DB에서 처리할 부분으로 분리하기도 한다. 견고한 n-티어 개발의 핵심은 각 계층의 명확한 분리이.. 더보기