/**
  * return logger
  * @return
  */
 public ILogger getLogger() {
  if(this.logger == null)
   return NullLogger.getInstance();
  
  return this.logger;
 }

아래는 로그를 남기는 예제코드입니다.

null-object.zip

위키피디아에 한 마디로 "Recombinable business logic in a boolean fashion" 이라고 나와 있습니다.

위키피디아의 한 마디는, 비지니스 로직 처리를 하기 위해서 if~else를 보통 많이 쓰는데, 그 if~else를 제거하고 비지니스 로직을 확장에 쉽게 Composition하는 패턴이라고 설명을 하는 것 이겠지요??
그리고, 로직이 다른 클래스가 하위 클래스로 점진적으로 추가 된다면, Strategy Pattern과 유사한 형태가 될 것 같습니다. 하지만, Strategy Pattern은 데이타에 대한 처리나 체크를 Concrete Strategy에서 하고 Specification Pattern은 모델의 Provider 클래스가 처리를 대행하는 형태라는게 다른 것 같습니다.

아래 링크도 참고하시면 좋을 듯 합니다.
http://en.wikipedia.org/wiki/Specification_pattern#C.23
http://decoder.tistory.com/877

아래는 예제 코드 입니다...

specification.zip

Reactor 패턴을 이용해서 자바로 네트워크 서버를 개발하다 보면, 하나의 Reactor로는 고 성능이 아니더라도 동접을 2000 이상 붙여보면 성능저하를 눈으로 확인해 볼 수 있습니다.. 그래서 Reator를 Master-Slave의 형태와 Slave Reactor를 cpu 갯수만큼 만들어서 성능을 높일 수 있습니다. 그러한 구조를 한눈에 알 수 있게 보여주는 그림입니다.. ^^

객체가 스스로 참조하는 객체를 생성하지 않고, 외부 환경(컨테이너)에서 삽입 되는 형태를 DI(Dependency Injection)라고 하네요.. ^^

DI 를 구현하는 방법은 2가지가 있네요..

1. Constructor 방식

Presentation Abstraction Control Pattern은 계층 형태의 시스템에서 각 단계별로 Agent를 가지고, Agent들이 계층적(상,하)으로 협력을 하는 구조가 필요할 때 사용할 수 있는 패턴이라고 하네요.. 각 Agent는 계층의 레벨에 맞는 기능을 담당합니다. 그리고 각 Agent는 Presentation, Abstraction, Control을 가질 수 있습니다.

제가 생각하는 내용을 아래의 형태별로 간단하게 코드로 끄적여 봅니다.
아래의 TopAgent는 데이타를 가지고 있고, InterMediateAgent는 mediate 기능을 담당하고 실제로 뷰는 BottomAgent를 통해서 구현을 합니다. 그리고, BottomAgent는 view()는 인터페이스로 뽑고, setter, getter 메쏘드는 Abstract Class를 통해서 여러개의 BottomAgent를 구현하면 좋을듯 합니다.

혹시 코드보시고, 틀렸다고 생각이 되시는 부분이 있으면 답글로 끄적여 주시면 감사하겠습니다

PACClient.java

TopAgent.java

InterMediateAgent.java

BottomAgent.java

Abstraction.java

Presentation.java

* reference
- http://en.wikipedia.org/wiki/Presentation-abstraction-control
- http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=126
- http://lakhos.egloos.com/2771689
 

Layer A.P. 어플케이션을 구조화하기 위해 서브 태스크(Subtask)들을 그룹으로 묶기 위해 분해한다. 공통된 추상 레벨에 있는 서브 태스크들끼리 묶어서 그룹으로 분류한다.

Pipes and Filters A.P. 데이터 스트림을 처리하는 시스템 구조를 제공한다. 각 프로세싱 단계는 필터 컴포넌트로 추상화한다. 데이터는 파이프를 통해 연관된 필터들에게 전달된다. 필터들을 다양하게 재조합하여 시스템을 재구축할 수 있다.

Blackboard A.P. 정의되지 않은 도메인에서의 문제를 해결할때 유용하다. 솔루션에 대한 부분적이거나 대략적인 해법을 수립하기 위해 몇가지 특수한 서브시스템들의 지식을 조합한다.

Broker A.P. 분산 소프트웨어 시스템을 구조화할때 유용하다. 분산 소프트웨어 시스템은 분리된 컴포넌트들이 서로 유기적으로 조합되어 운영되는 시스템으로, 이러한 컴포넌트들 간의 통신을 관장하는 역활을 하는 것이 Broker이다.

Model-View-Controller A.P. 모델은 핵심기능과 데이터를 의미하고 뷰는 기능에 의한 데이터의 표현이며 컨트롤은 사용자의 입력에 대한 처리이다. 뷰와 컨트롤러는 사용자의 인터페이스를 구성하며 사용자 인터페이스와 모델간의 일관성 및 정합성을 보장한다.

Presentation-Abstraction-Control A.P. 계층구조를 이루는 에이전트들이 상호작용하는 소프트웨어 시스템에 대한 패턴. 각각의 에이전트는 하나의 어플리케이션의 특정 부분을 전담하며 에이전트는 프리젠테이션/추상/컨트롤로 구성된다.

Microkernel A.P. 변화하는 시스템에 대한 요구사항을 수용할 수 있도록 하는 패턴. 시스템에서 가장 최하단에 위치하는 핵심 기능을 추출해 내며, 추가된 요구사항에 대해 확장기능으로 정의하여 시스템에 손쉽게 추가할 수 있도록 한다.

Reflection A.P. 소프트웨어 시스템의 구조와 동작을 동적으로 변경할 수 있는 메커니즘을 제공.

Whole-Part D.P. 전체(Whole) 객체를 구성하는 컴포넌트(Part)를 정의한다. Whole 객체를 통해 Part 컴포넌트들의 관계를 맺으며, 이 Whole 객체를 통해서만 Part 컴포넌트와 통신할 수 있다.

Master-Slave D.P. 마스터 컴포넌트는 슬레이브 컴포넌트에게 작업을 분산시켜서 최종적으로 슬레이브로부터 그 결과를 취합한다.

Proxy D.P. 실제 컴포넌트가 아닌 대리자를 앞단에 두어 이 대리자를 통해 실제 컴포넌트와 통신을 한다. 실제 컴포넌트의 위치 추상화, 실제 컴포넌트를 사용하기 위한 인증 등과 같은 전처리는 물론 후처리에 대한 기능 추가가 용이하다.

Command Processor D.P. 사용자의 요청을 하나의 객체로 정의하여 관리하며 Undo/Redo와 같은 처리가 가능하다.

View Handler D.P. 시스템의 모든 뷰를 관리하는 책임을 분리하여 뷰들 간의 관계성과 연관된 작업을 쉽게 처리할 수 있도록 한다.

Forwarder-Receiver D.P. 투명한 IPC를 제공하고 Peer를 분리하기 위해 Forwarder와 Receiver를 분리한다.

Client-Dispatcher-Server D.P. 클라이언트와 서버 사이에 디스패처 레이어를 도입한다. 위치 투명성을 제공하고 클라이언트와 서버간의 통신에 대한 세부적인 구현을 캡출화한다.

Publisher-Subscriber D.P. 서로 긴밀하게 관계를 맺고 있는 컴포넌트들 간의 상태에 대해 정합성을 유지하는데 용이하다. Publisher가 책임을 지고 하나의 변경에 대해 다수의 Subscriber에게 변경을 통지한다.

public class ExceptionLogger  
{  
    public void Log(Exception ex)  
    {  
        Console.WriteLine("An exception has occurred.");  
        Console.WriteLine(ex.ToString());  
    }  
} 
-------------------------------------------------------------------------------------------------------------------------
public class FileExceptionLogger  
{  
    public void Log(Exception ex, string fileName)  
    {  
        using (StreamWriter sw = new StreamWriter(fileName))  
        {  
            sw.WriteLine(ex.ToString());  
        }  
    }  
}  
 
public class EmailExceptionLogger  
{  
    public void Log(Exception ex, string server, string toAddress)  
    {  
        MailMessage msg = new MailMessage("errors@testcompany.com", toAddress);  
        msg.Subject = "An exception has occurred.";  
        msg.Body = ex.ToString();  
        SmtpClient client = new SmtpClient(server);  
    client.Send(msg);  
    }  
} 
-------------------------------------------------------------------------------------------------------------------------
// 위의 화면, 파일, 이메일 로그에 대해서 개별적인 기능 제공에 대한 문제
public static void Main(string[] args)  
{  
    ExceptionLogger log = new ExceptionLogger();  
    FileExceptionLogger fileLogger = new FileExceptionLogger();  
    EmailExceptionLogger emailLogger = new EmailExceptionLogger();  
 
    try 
    {  
        NestedException();  
    }  
    catch (Exception ex)  
    {  
        log.Log(ex);  
        fileLogger.Log(ex, "errors.log");  
        emailLogger.Log(ex, "localhost", "myemail@testcompany.com");  
    }  
} 
-------------------------------------------------------------------------------------------------------------------------
// 위의 개별 클래스, 개별기능으로 인해서 로깅에 대한 모듈이 확장성이 없어지는 문제를 아래와 같이 해결할 수 있다는 내용입니다.

public interface ExceptionLogger  
{  
    public abstract void Log(Exception ex);  
}  
 
public class ConsoleExceptionLogger : ExceptionLogger  
{  
    public void Log(Exception ex)  
    {  
        Console.WriteLine("An exception has occurred.");  
        Console.WriteLine(ex.ToString());  
    }  
}  
 
public class FileExceptionLogger : ExceptionLogger  
{  
    public void Log(Exception ex)  
    {  
        // can't really do anything without a filename  
        // just want to fill out the interface.  
    }  
 
    public void Log(Exception ex, string fileName)  
    {  
        using (StreamWriter sw = new StreamWriter(fileName))  
        {  
            sw.WriteLine(ex.ToString());  
        }  
    }  
}  
 
public class EmailExceptionLogger : ExceptionLogger  
{  
    public void Log(Exception ex)  
    {  
        // see Log(Exception) on FileExceptionLogger  
    }  
 
    public void Log(Exception ex, string server, string toAddress)  
    {  
        MailMessage msg = new MailMessage("errors@testcompany.com", toAddress);  
        msg.Subject = "An exception has occurred.";  
        msg.Body = ex.ToString();  
        SmtpClient client = new SmtpClient(server);  
    client.Send(msg);  
    }  
} 
-------------------------------------------------------------------------------------------------------------------------
// 위는 로깅에 대한 모듈이 확장성이 있지만 개별기능에 대해서 호출하는 문제를 아래와 같이 공통기능으로 뽑아서 공통 메쏘드를 호출할 수 있도록 해 주는 솔루션입니다.

public class FileExceptionLogger : ExceptionLogger  
{  
    private readonly string fileName;  
    public FileExceptionLogger(string file)  
    {  
        this.fileName = file;  
    }  
 
    public void Log(Exception ex)  
    {  
        using (StreamWriter sw = new StreamWriter(fileName))  
        {  
            sw.WriteLine(ex.ToString());  
        }  
    }  
}  
 
public class EmailExceptionLogger : ExceptionLogger  
{  
    private readonly string server;  
    private readonly string toAddress;  
    public EmailExceptionLogger(string smtpServer, string to)  
    {  
        this.server = smtpServer;  
        this.toAddress = to;  
    }  
 
    public void Log(Exception ex)  
    {  
        MailMessage msg = new MailMessage("errors@testcompany.com", toAddress);  
        msg.Subject = "An exception has occurred.";  
        msg.Body = ex.ToString();  
        SmtpClient client = new SmtpClient(server);  
    client.Send(msg);  
    }  
} 

MVC 패턴에 대한 내용입니다.
아래 내용은 http://en.wikipedia.org/wiki/Model-view-controller 에서 정의한 내용입니다.

Model

The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database ) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

View

Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

Controller

Processes and responds to events, typically user actions, and may invoke changes on the model.

An Aggregation is an Association which denotes an "is part of" relationship. Unfortunately, the definition of this relationship is quite lax, so basically everyone is using his own interpretation. The only definitive (?) property is that in an instance graph, aggregations are not allowed to be circular - that is, an object can not be "a part of itself". (or) When building new classes from existing classes using aggregation, a composite object built from other constituent objects that are its parts.Java supports aggregation of objects by reference,since objects can't contain other objects explicitly.

A Composition adds a lifetime responsibility to Aggregation. In a garbage collected language like Java it basically means that the whole has the responsibility of preventing the garbage collector to prematurely collect the part - for example by holding a reference to it. (In a language like C++, where you need to explicitely destroy objects, Composition is a much more important concept.) Only one whole at a time can have a composition relationship to a part, but that relationship doesn't need to last for the whole lifetime of the objects - with other words, lifetime responsibility can be handed around.

Aggregation and Composition Guidelines :

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on. A delivery shipment contains one or more packages. A team consists of two or more employees. These are all examples of the concept of aggregation, which represents 밿s part of?relationships. An engine is part of a plane, a package is part of a shipment, and an employee is part of a team. Aggregation is a specialization of association, specifying a whole-part relationship between two objects. Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. From a stylistic point of view, because aggregation and composition are both specializations of association the guidelines for associations apply.

출처는 http://faq.javaranch.com/java/AssociationVsAggregationVsComposition 입니다.

Object-Oriented Analysis and Design (OOAD) is a software engineering approach that models a system as a group of interacting objects.

Object-Oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system.

Object-Oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.