백업] 네이버 40

객체설계 javagame.cafe에서 펌. java

2004/09/03 11:49 수정 삭제

http://blog.naver.com/wiggyz/80005431086

//주소록 프로그램 프로젝트를 통해 알아보는 객체설계 - 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들을 만들어 왔다. /* UI 밖에 모르는 개발자 */ 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와 같기를 염원하며...