객체지향 설계 쉽게 생각하기

http://mjava.net/bbs/view.php?id=tip_tech&no=40


주소록 프로그램 프로젝트를 통해 알아보는 객체설계 - 1. 전문분야별 Separation Of Concerns


1. 프로젝트 상황:
프로젝트는 기간이 짧으며 또한 예산도 제한되어 있다.

2. 개발자 상황:

현재 갖춘 개발자는 4명이며 개발자 D를 제외한 나머지 개발자 A,B,C는 각자 UI만 만들줄 아는 사람, 업무 흐름만 아는 사람, 그리고 SQL과 JDBC를 통해 database 처리만 할 줄 아는 사람이 있다.
다행히 개발자 D는 각 분야에 대해서 어느정도 지식을 가지고 있지만 그렇다고 개발자 D혼자서 시스템을 다 만들 수는 없다.
기간이 제한 되어 있기 때문이다.

4. 방안:
방법은 분업 즉, 각자의 분야해서 전문성을 가진 개발 부분만을 분리해서 개발하는 분업이 필요하다.
똘똘한 개발자 D는 다년간의 개발 경험을 바탕으로 다음의 3개 base class를 만들어 분업을 할 수 있는 골격 클래스를 만들었다.


public class Presentation{

    BusinessLogic businessLogic;

    public Presentation(BusinessLogic bl){
        businessLogic = bl;
    }

    public BusinessLogic getBusinessLogic(){
            return businessLogic;
    }

    public void doPresentation(){
        //비워둠
    }
}

public class BusinessLogic{
    Database database;

    public BusinessLogic(Database db){
        database = db;
    }

    public Database getDatabase(){
        return database;
    }

    public void doBusinessLogic(){
        //비워둠
    }
}


public class Database{

    public void save(){
        //비워둠
    }

    public void load(){
        //비워둠
    }
}

또한 똘똘한 개발자 D는 이렇게 했을때 시스템이 원활하게 돌아가는지 확인해보기 위해 다음의 prototype클래스를 만들어
각 클래스들이 유기적으로 잘 동작하는지 확인해보았다.

public class Application {

    public static void main(String args[]){

    Presentation presentation =
        new Presentation(
            new BusinessLogic(
                new Database()
            )
        );

    presentation.doPresentation();

    }
}

해보니까 잘 돌아가더라.. 그래서 이렇게 해놓고 똘똘하면서 잡다하게 많이 아는 개발자 D는 자기 분야에서 묵묵히 일하는 개발자 A,B,C를 불러모아 놓고
각 개발자들이 준수해야할 위의 3가지 클래스들을 넘겨주었다. 1주일후 개발자 A,B,C는 각각 다음의 derived class들을 만들어 왔다.



/*
System.out.println() 밖에 모르는 개발자
*/

public class AddressBookPresentation extends Presentation{

    public AddressBookPresentation(BusinessLogic businessLogic){
        super(businessLogic);
    }

    public void doPresentation(){
        System.out.println("결과값은: " + getBusinessLogic().doBusinessLogic() + " 입니다.");
    }

}


/*
업무 흐름 밖에 모르는 개발자
*/

public class AddressBookBusinessLogic extends BusinessLogic{

    public AddressBookBusinessLogic(Database database){
        super(database);
    }

    public void doBusinessLogic(Database database){
        getDatabase().save();
        getDatabase().load();
    }

}


/*
JDBC 밖에 모르는 개발자
*/

public class AddressBookDatabase extends Database{

    public void save(){
        sql.query("insert into addressBook values(???)");
    }

    public void load(){
        sql.query("select ??? from addressBook");
    }

}


그 사이에 개발자 D는 시스템 전반에 발생할 수 있는 여러가지 문제들을 고민하고 필요할때 마다 개발자 A, B, C와 협의 했다.
자신은 전체 시스템을 동작할 Application class를 만드는 막중한 업무가 있다고 하면서 사실은 줄곧 놀았다. 개발자 D가 작성한 코드는 다음과 같이 처음에 만든것에 클래스명만 몇개 바꿨다.

/*
세부기술 관심없고 전체흐름만 아는 설계자
*/

public class AddressBookApplication {

    public static void main(String args[]){

    Presentation presentation =
        new AddressBookPresentation(
            new AddressBookBusinessLogic(
                new AddressBookDatabase()
            )
        );

    presentation.doPresentation();

    }
}


그렇게 4개의 클래스는 미리 각자의 영역에 대한 메서드 관계를 미리 정의 했기때문에 서로 연결되어 바로 동작했다.
개발자 A,B,C는 개발자 D가 무슨 요술을 부린게 아닌가 의심했다.

각자의 영역에서만 개발을 했기 때문에 일은 아주 빠르게 진행되었다. 또한 경험많은 개발자 D가 작성해준 base class들은
각자의 개발자가 참조할 다른 영역의 필요한 왠만한 메서드들이 거의 다 갖추고 있었기 때문에 서로 타협해야 할 부분이 적었다.

또한 이렇게 해놓고 나니 다음과 같은 상황에서도 개발자 D는 유연히 대처했다.

상황 1. 고객이 시스템 UI를 Window version으로 변경을 요구함

Presentation 개발자인 개발자 A를 불러 AddressBookWindowPresentation을 만들어오라고 주문


public class AddressBookWindowPresentation extends AddressBookPresentation{

    public AddressBookWindowPresentation(BusinessLogic businessLogic){
        super(businessLogic);
    }

    public void doPresentation(){
        Frame frame = new Frame();
        frame.add( new Label ("결과값은: "+ getBusinessLogic().doBusinessLogic() + " 입니다."));
        frame.show();
    }
}

그리고 다음과 같이 Application을 살짝 바꾼후

public class AddressBookWindowApplication {

    public static void main(String args[]){

        Presentation presentation =
            new AddressBookWindowPresentation( // <== 요기만 바꿈
                new AddressBookBusinessLogic(
                    new AddressBookDatabase()
                )
            );

        presentation.doPresentation();
    }
}

고객에게 갖다줬음



상황 2. 고객사의 업무 로직이 변경되었다

개발자 B만 불러서 AddressBookBusinessLogic class의 extension class 작성요구
상황 1처럼 클래스 명 바꾸고 고객한테 갖다줌


상황 3. 기존에 Oracle만 썼는데, 고객사의 지점에서는 SQL server 2000을 주로 사용하고 있어 시스템의 변경버전을 요구함

개발자 C를 불러서 SQL Server 2000용 SQL문으로 구성된 AddressBookDatabaseSQL2000 작성을 요구함 마찬가지로 했음


* 각각의 상황에서 변경이외의 클래스들은 영향 받지 않고 다른 부분의 개발자들이 참여할 필요도 없었다.

어찌 된것인지 고객측이 어떤 천진난만한 요구를 해와도 개발자 D는 항상 여유로왔다..

몇 년후에 개발자 D는 자기가 했던 프로젝트들에서 나온 많은 양의 클래스들을 가지고 무슨 Framework인가 하는 이름으로

솔루션을 만들어 팔아먹고 있었다...


*** 참고로 위에 설명된 모든 상황은 오직 개발자 D가 PM을 맡았을 경우에만 가능하다.


세상의 모든 PM이 개발자 D와 같기를 염원하며...
-------
출처 자바스터디