검색결과 리스트
IT/Archi & Design에 해당되는 글 3건
- 2010/12/27 계약에 의한 설계(Design by Contract;DBC)
- 2010/10/20 Design Pattern Summary
- 2009/11/23 OOPrinciples SOLID
글
계약에 의한 설계(Design by Contract;DBC)
IT/Archi & Design
2010/12/27 13:55
계약에 의한 설계(Design By Contract, 이하 DBC)는 아이펠(Eiffel)이라는 언어를 만든 버트란드 마이어가 개념을 개발하였다. 이것은 프로그램 모듈들의 책임을 문서화하는데 초점을 맞춘다. 각각의 모듈이 가져야 하는 기능만큼만 동작하도록 한다. 이러한 개념을 문서화하고 검증하는 것이 바로 DBC의 핵심이다.
모듈이 동작할 때, 어떠한 인자를 넣어주어야 하는지, 어떤 결과를 원하는지 등이 있는데, DBC에서는 모듈을 호출하기 위해 참이어야 하는 것을 선행조건(Precondition), 모듈이 자기가 할 것이라고 보장하는 것을 후행조건(Postcondition)이라고 한다. 또, 불변식(Invariant)이라는 것이 있는데, 호출자의 입장에서 이 조건이 언제나 참이라고 보장하는 것을 말한다. 모듈이 내부 처리 중에는 불변식이 참이 아닐 수도 있지만, 모듈이 종료하고 호출자로 제어권이 반환되는 때에는 참이 되는 것이다.
여기서의 계약은 호출자와 피호출자에 해당하는 계약이다. 계약 조건은 아래와 같이 명시되어 있다.
만약 호출자가 모듈(루틴)의 모든 선행조건을 충족한다면, 해당 모듈은 종료시 모든 후행조건과 불변식이 참이 될 것을 보증해야 한다.
예를 들어, Person이라는 클래스의 이름을 설정하는 setName 이라는 메소드가 있다고 치자, setName 메소드는 아래와 같은 형태일 것이다.
class Person{
private String name;
pulbic void setName(final String name){
this.name = name;
}
public String getName(){
return this.name;
}
}
private String name;
pulbic void setName(final String name){
this.name = name;
}
public String getName(){
return this.name;
}
}
그렇다면 setName 메소드가 가져야 할 선행조건과 후행조건이 무엇인가. 선행조건은 인자로 받아오는 name이 null 값이 되어서는 안된다는 것이다. 후행조건은 모듈이 실행되고 나서 Person 클래스의 name이 제대로 변경되는 것이다. 그렇게 선행조건과 후행조건이 만족한다면 계약이 이행되는 것이다.
setName 메소드에 대한 DBC를 아래와 같이 구현할 수 있다.
...
/**
* @pre name != null
* @post getName() == name
*/
pulbic void setName(final String name){
this.name = name;
}
...
/**
* @pre name != null
* @post getName() == name
*/
pulbic void setName(final String name){
this.name = name;
}
...
앞에서도 말했듯이, 아이펠은 DBC를 지원한다. 또한 C/C++에서도 Nana를 통해 지원한다. Java에서는 iContract, Contract4J, c4j 등을 통해 DBC를 구현할 수 있다.
DBC는 어디에 유리할까? 아마도 문제가 발생한 경우, 문제를 찾고 원인을 밝히는데 사용하면 좋을 것이다. 또한 문제의 책임을 규명하는 데도 효과적일 것이다. 어떠한 모듈이 어떠한 호출에 의해 문제가 발생하였는지, 어떤 모듈의 책임인지 쉽게 알 수 있을 것이다.
그런데 이렇게 효과적인 DBC는 왜 널리 쓰이지 않을까?
[참고 : 실용주의 프로그래머]
'IT > Archi & Design' 카테고리의 다른 글
| 계약에 의한 설계(Design by Contract;DBC) (0) | 2010/12/27 |
|---|---|
| Design Pattern Summary (0) | 2010/10/20 |
| OOPrinciples SOLID (0) | 2009/11/23 |
글
Design Pattern Summary
IT/Archi & Design
2010/10/20 10:34
'IT > Archi & Design' 카테고리의 다른 글
| 계약에 의한 설계(Design by Contract;DBC) (0) | 2010/12/27 |
|---|---|
| Design Pattern Summary (0) | 2010/10/20 |
| OOPrinciples SOLID (0) | 2009/11/23 |
글
OOPrinciples SOLID
IT/Archi & Design
2009/11/23 09:10
- 상세 설계나, 디자인 설계 과정에서
SOLID part 1: Single Responsibility Principle
http://giorgiosironi.blogspot.com/2009/09/solid-part-1-single-responsibility.html
"There can be only one reason for a class to change."
- 분할통치(Divide and Rule)라고도 함.
- 실제로 복잡한 부분을 추상화하는 것이 핵심
- 클래스의 행위를 한 문장으로 기술해 보는 것이 이 원칙을 적용하는데 도움이 됨.
- 클래스의 재사용성 향상, 클래스가 간단해져 유지보수성 향상, fine-grained 설계 촉진, 테스트 용이
SOLID part 2: Open/Closed Principle
http://giorgiosironi.blogspot.com/2009/09/solid-part-2-openclosed-principle.html
"Classes and methods should be open for extension but closed for modification."
이 원칙을 따르는 사례
- programming to an interface, not an implementation
- template method pattern
- iterator pattern
- Every good pattern resemble the OCP
- extending behavior without cluttering a base unit
- OCP를 달성하는데 Encapsulation가 도움됨
- OCP forces decoupled and extendable code
SOLID part 3: Liskov Substitution Principle
http://giorgiosironi.blogspot.com/2009/09/solid-part-3-liskov-substitution.html
"Every function or method which expects an object parameter of class A must be able to accept a subclass of A as well, without knowing it."
- 하위 클래스는 언제나 원래 클래스로 대체될 수 있어야 함
- 상속은 Is-A 관계일 때만
SOLID part 4: Interface Segregation Principle
http://giorgiosironi.blogspot.com/2009/09/solid-part-4-interface-segregation.html
"Classes should not depend on interfaces that they not use."
- small interface
- small interface -> less polluted interface -> simplicity of implementation -> less methods -> less tests and less interaction which can cause bugs
- much more cohesive
SOLID part 5: Dependency Inversion Principle
http://giorgiosironi.blogspot.com/2009/09/solid-part-5-dependency-inversion.html
"High level classes should not depend on low level classes. Both should depend upon abstractions. Details should depend upon abstractions. Abstractions should not depend upon details."
- The purpose of this principle is to enable decoupling of software modules.
- The problem with dependency is the transitivity.
- dependency injection을 이용하여 testability를 높인다.
※ 자료출처 : <딱딱하고 재미없게 살아가기>
'IT > Archi & Design' 카테고리의 다른 글
| 계약에 의한 설계(Design by Contract;DBC) (0) | 2010/12/27 |
|---|---|
| Design Pattern Summary (0) | 2010/10/20 |
| OOPrinciples SOLID (0) | 2009/11/23 |
