티스토리 뷰
▶ 디자인 패턴 적용시 중요한 세가지 규칙
1. Implementation class 가 아닌 interface 를 이용 하는게 좋다.
2. Inheritance 가 아닌 Delegation 을 사용
public interface AA {
public String getInfo();
}
public class Super implements AA {
public String getInfo() {}
}
public class Sub {
AA delegator;
public void test() {
delegator.getInfo();
}
}
cf ) white-box reuse : Inheritance vs. black-box reuse : Delegation
물론 상속을 사용하여하는 경우도 있다.
3. Coupling 의 최소화
* 커플링 : 어느 하나의 기능 변화가 전체 시스템의 구조에 영향을 미치는 정도
> 이것이 커질수록 잘못된 디자인
>> Refactoring 과 design pattern
> 실제 문제 분석이 종료된 이후 좀더 효율적인 코드로 변화시키는 것을 refactoring 이라 한다.
> 이 과정에서 디자인패턴이 적용되어지는 경우가 많다
> 구현하기 이전에 보지 못했던 디자인상의 문제점들을 실제 구현에 들어가 이를 개선하는 것
리펙토링에 관련된 책은 마틴 파울러의 리펙토링이라는 책이 번역되어 출판되어 있다.
>> Anti-Pattern
> s/w 를 만드는 과정에서 쉽게 도출되는 바람직하지 않은 방법들
> 종류
- 관리상의 안티
- architecture 상의 안티
- 개발상의 안티
> 대표적인 anti-pattern
- Spaghetti code : 개발과정에서 나타남. 기능의 추가로 인해 코드의 복잡도가 증가, 꼬이는 현상
- Stovepipe System : architecture의 문제, 확실한 추상화가 없이 하나로 묶어 제품을 만드는 경우
신뢰성, 유지보수가 모두 저하
- Analysis Paralysis : 분석단계에서 너무 완벽함을 추구하다보면 개발 진행 자체가 마비
- Swiss Army Knife : architecture 작성시 하나의 객체에 너무 많은 기능/인터페이스를 넣는 경우 복잡,
유지보수 난이, 커플링 증가
- Ambiguous Viewpoint : 불명확한 상태에서 모델링을 진행 -> 객체의 불명확
1. Implementation class 가 아닌 interface 를 이용 하는게 좋다.
2. Inheritance 가 아닌 Delegation 을 사용
public interface AA {
public String getInfo();
}
public class Super implements AA {
public String getInfo() {}
}
public class Sub {
AA delegator;
public void test() {
delegator.getInfo();
}
}
cf ) white-box reuse : Inheritance vs. black-box reuse : Delegation
물론 상속을 사용하여하는 경우도 있다.
3. Coupling 의 최소화
* 커플링 : 어느 하나의 기능 변화가 전체 시스템의 구조에 영향을 미치는 정도
> 이것이 커질수록 잘못된 디자인
>> Refactoring 과 design pattern
> 실제 문제 분석이 종료된 이후 좀더 효율적인 코드로 변화시키는 것을 refactoring 이라 한다.
> 이 과정에서 디자인패턴이 적용되어지는 경우가 많다
> 구현하기 이전에 보지 못했던 디자인상의 문제점들을 실제 구현에 들어가 이를 개선하는 것
리펙토링에 관련된 책은 마틴 파울러의 리펙토링이라는 책이 번역되어 출판되어 있다.
>> Anti-Pattern
> s/w 를 만드는 과정에서 쉽게 도출되는 바람직하지 않은 방법들
> 종류
- 관리상의 안티
- architecture 상의 안티
- 개발상의 안티
> 대표적인 anti-pattern
- Spaghetti code : 개발과정에서 나타남. 기능의 추가로 인해 코드의 복잡도가 증가, 꼬이는 현상
- Stovepipe System : architecture의 문제, 확실한 추상화가 없이 하나로 묶어 제품을 만드는 경우
신뢰성, 유지보수가 모두 저하
- Analysis Paralysis : 분석단계에서 너무 완벽함을 추구하다보면 개발 진행 자체가 마비
- Swiss Army Knife : architecture 작성시 하나의 객체에 너무 많은 기능/인터페이스를 넣는 경우 복잡,
유지보수 난이, 커플링 증가
- Ambiguous Viewpoint : 불명확한 상태에서 모델링을 진행 -> 객체의 불명확
'어플리케이션' 카테고리의 다른 글
자바 APP에서의 디버깅 방법 (0) | 2008.02.18 |
---|---|
프로젝트 막판 짧은 소고 (0) | 2008.01.31 |
프로그래머 타입 10가지 zdnet 기사에서 스크랩 (0) | 2008.01.08 |
VC++ 프로젝트 명 변경 (0) | 2007.12.12 |
Vista 에서 권한상승할 수 있는 ActiveX Component 만들기 (0) | 2007.12.04 |
[자료구조] 1st Stack (0) | 2007.12.02 |
웹 시스템 성능 진단 사례 및 가이드 라인 첫번째 (0) | 2007.10.09 |
The Joel Test: 나은 코딩을 위한 12단계 (0) | 2007.10.01 |
자바스크립트 라이브러리 모음집 (0) | 2007.10.01 |
[디자인패턴] 디자인 패턴 분류 (0) | 2007.10.01 |
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- 다짐
- DB
- Datapump
- auto increment
- 커뮤니케이션의 7가지 나쁜 습관들
- 아웃라이어
- 꿈
- 구조주의 인류학
- 큐브리드
- 데이터과학
- 카이에 소바주 시리즈
- 셀프 조인
- getGeneratedKeys
- 프로젝트
- shared everything
- 바이오해킹
- 튜닝
- shared all
- NHN 면접
- 오라클
- 구글
- 브레인피드백
- 습관의힘
- 일본전산
- CUBRID
- ChatGPT
- 성공의길
- oracle
- 퇴사
- 디자인패턴
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
글 보관함