2006/06/03 01:16 Developer
객체지향 SW설계의 원칙 - Open-Closed Principle
개방-패쇄 원칙( Open-Closed Principle)
http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39134727,00.htm
확장되는 것은 변하지 않은 것을 엄격히 구분해야 한다. 변하는 것은 가능한 변하기 쉽게, 변하지 않는 것은(패쇄돼야 하는 것은) 변하는 것에 영향을 받지 않게 설계를 한다. 다음으로 두 모듈이 만나는 지점에 인터페이스를 정의해야 한다. 변하는 것과 변하지 않는 모듈의 교차점으로 서로를 보호하는 방죽역할을 한다.
서버에 있어서 인터페이스는 확장의 내용이 정의되고 이 규약에 따라 확장이 구체화하는 역할을 한다. 따라서 인터페이스는 서비스 내용을 추상화하는 형태로 제공되므로 인터페이스 설계에 주의가 필요하다. 또한 인터페이스는 클라이언트에 있어서 서버의 확장,변경에 따른 클라이언트의 변경을 무색하게 하는 방패가 된다. 서버에서는 인터페이스 규약에 의해서만 확장 변경되기 때문이다. 따라서 안정된 계약에 의한 설계를 보장한다.
객체간의 관계를 단순화해 복잡도를 줄이고, 확장,변경에 따른 충격을 줄이는 데 있다.
주의사항
객체지향원칙 - 이용현님 블로그
http://blog.naver.com/tb/yohlee93/30005284579
C언어를 하다가 C++과 자바를 한 것이 2000년도인가 봅니다. 객체지향을 억지로 머릿속에 넣고, 개념없이 사용을 했던거 같습니다. 10년에 절반정도 시간이 되니, 이제 조금씩 객체지향이 눈에 보이기 시작합니다. 그래서 저도 다시 객체지향과 패턴 등등을 다시 살펴보고 있죠. 어린 시절에 잘 안보이던 글귀들이 이제는 조금씩 보이기 시작하네요
물론, 개념 자체가 시간이 흐르면서 더 완숙해지고, 많은 best practice들이 나와서 좀더 활용이 가능한 실질적인 패턴과 권장/추천하는 방식이 생겨나고, 많은 프레임워크들이 등장을 했습니다. Struts, webwork, Spring 등등도 중요하지만, 그것들이 만들어질 수 밖에 없었던 필연적인 이유는 좀더 객체지향을 잘 하기 위함이 아닐까 생각해 봅니다. 단순하게 프레이워크를 사용하는데 그치지 않고, 좀더 객체지향적으로 디자인이 잘된 어플리케이션을 설계할 수 있으면 좋겠습니다...^^
http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39134727,00.htm
확장되는 것은 변하지 않은 것을 엄격히 구분해야 한다. 변하는 것은 가능한 변하기 쉽게, 변하지 않는 것은(패쇄돼야 하는 것은) 변하는 것에 영향을 받지 않게 설계를 한다. 다음으로 두 모듈이 만나는 지점에 인터페이스를 정의해야 한다. 변하는 것과 변하지 않는 모듈의 교차점으로 서로를 보호하는 방죽역할을 한다.
서버에 있어서 인터페이스는 확장의 내용이 정의되고 이 규약에 따라 확장이 구체화하는 역할을 한다. 따라서 인터페이스는 서비스 내용을 추상화하는 형태로 제공되므로 인터페이스 설계에 주의가 필요하다. 또한 인터페이스는 클라이언트에 있어서 서버의 확장,변경에 따른 클라이언트의 변경을 무색하게 하는 방패가 된다. 서버에서는 인터페이스 규약에 의해서만 확장 변경되기 때문이다. 따라서 안정된 계약에 의한 설계를 보장한다.
객체간의 관계를 단순화해 복잡도를 줄이고, 확장,변경에 따른 충격을 줄이는 데 있다.
주의사항
- 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면 오히려 관계가 더 복잡해져서 설계를 망치는 경우가 있다. 설계자의 좋은 자질 중 하나는 이런 크기 조절과 같은 갈등 상황을 잘 포착하여 비장한 결단을 내릴 줄 아는 능력에 있다.
- 확장을 보장하는 open모듈 영역에서 예측하지 못한 타입을 만났을 때 인터페이스를 변경하려는 안과 어댑터를 사용하려는 안 사이에서 갈등하게 된다. 보통 후자를 선택한다. 한번 정해진 인터페이스는 시간이 갈수록 사용하는 모듈이 많아지기 때문에 바꾸는데 엄청난 출혈을 각오해야 한다. 즉, 인터페이스는 가능하면 변경해서는 안된다. 따라서 인터페이스를 정의할 때 여러 경우의 수에 대한 고려와 예측이 필요하다. 물론 과도한 작업은 불필요한 작업을 만든다. 설계자는 적절한 수준의 예측 능력이 필요한데, 설계자의 또 하나의 자질은 예지력이다
- 인터페이스 설계에서 적당한 추상화 레벨을 선택하는 것이 중요하다. 추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징이다.
객체지향원칙 - 이용현님 블로그
http://blog.naver.com/tb/yohlee93/30005284579
C언어를 하다가 C++과 자바를 한 것이 2000년도인가 봅니다. 객체지향을 억지로 머릿속에 넣고, 개념없이 사용을 했던거 같습니다. 10년에 절반정도 시간이 되니, 이제 조금씩 객체지향이 눈에 보이기 시작합니다. 그래서 저도 다시 객체지향과 패턴 등등을 다시 살펴보고 있죠. 어린 시절에 잘 안보이던 글귀들이 이제는 조금씩 보이기 시작하네요
물론, 개념 자체가 시간이 흐르면서 더 완숙해지고, 많은 best practice들이 나와서 좀더 활용이 가능한 실질적인 패턴과 권장/추천하는 방식이 생겨나고, 많은 프레임워크들이 등장을 했습니다. Struts, webwork, Spring 등등도 중요하지만, 그것들이 만들어질 수 밖에 없었던 필연적인 이유는 좀더 객체지향을 잘 하기 위함이 아닐까 생각해 봅니다. 단순하게 프레이워크를 사용하는데 그치지 않고, 좀더 객체지향적으로 디자인이 잘된 어플리케이션을 설계할 수 있으면 좋겠습니다...^^
