본문 바로가기

CBD12

Component Refactoring [6] 구현 컴포넌트 분석 - 컴포넌트 내부 분석 컴포넌트의 내부 분석은 상당한 노력과 시간이 요하는 작업이다. 특히, 이 작업을 수행할 때에는 내부 로직을 하나씩 세부적으로 분석할 필요가 있으며, 그러한 분석 내용은 차후를 위해 정리하는 작업도 같이 병행되면 더 좋다. 컴포넌트의 내부는 관련된 객체가 서로 결속력이 강한 형태를 이루어야 하는데, 컴포넌트 리팩토링 단계에서는 내부 결속력이 강하지 못한 객체를 중심으로 식별하여 리팩토링 대상을 삼는다. 또한, 더 세부적으로 기능의 유사성을 식별하여 재사용 가능한 형태의 구조까지도 리팩토링을 수행할 수 있다. 유형 - 너무 많거나 적은 책임성(Responsibility)을 가지는 클래스가 발생하는 현상. - 타 클래스와 협업(Collaboration)이 적은 클래스.. 2008. 11. 19.
Component Refactoring [5] 구현 컴포넌트 분석 - 컴포넌트 크기 분석 컴포넌트는 적절한 크기로 만들어져야 하며, 그 크기는 상대적으로 관리할 수 있는 형태이어야 한다. 즉, 컴포넌트는 독립적인 비즈니스 개념 및 프로세스를 담고 있어야 한다. 컴포넌트 크기는 인터페이스 갯수, 인터페이스의 오퍼레이션 갯수, 컴포넌트가 호출하는 다른 컴포넌트의 인터페이스 갯수 등 다양한 기준으로 측정이 가능하며, 각각의 경우에 있어서 적절한 기준을 선정해야 한다. 유형 - 하나의 컴포넌트가 너무 많은 인터페이스를 가지고 있는 현상. - 하나의 인터페이스에 서로 성격이 다른 유형의 오퍼레이션을 가지고 있는 현상. - 하나의 오퍼레이션이 너무 많은 기능을 수행하는 현상. - 하나의 인터페이스가 너무 적은 수의 오퍼레이션을 가지고 있는 현상. 분석 내용 -.. 2008. 11. 18.
Component Refactoring [4] 구현 컴포넌트 분석 - 컴포넌트 Dependency 파악 컴포넌트 Dependency는 현재 구현된 컴포넌트의 의존관계에서 원칙에 위배되는 내용을 파악하는 단계이다. 이 단계에서는 이러한 의존관계의 위배 현상의 피상적인 결과 뿐만 아니라, 왜 그와 같은 의존관계가 형성될 수 밖에 없는지의 원인까지도 가능한 파악되어야 한다. 이러한 컴포넌트 의존관계 원칙은 컴포넌트 설계 전에 우선 결정이 되어야 하며, 설계를 진행하고 구현하는 과정에서 이러한 피드백을 받아서 다시 의존관계를 조정해야 한다. 유형 의존관계가 위배되는 유형은 아래와 같이 크게 세가지 형태로 나뉠 수 있다. - Dependency 의 역전 현상 (엔티티에서 프로세스로의 호출, 유틸리티에서 프로세스 혹은 엔티티로의 호출) [1] - Depende.. 2008. 11. 17.
Component Refactoring [3] 컴포넌트 리팩토링은 구현 컴포넌트 분석, 리팩토링 목적 및 범위 설정, 방안 마련, 리팩토링 수행, 테스팅으로 나뉠 수 있다. 각 단계에서는 컴포넌트가 가지는 여러가지 측면에서 단계별로 접근하게 된다. 전체적인 컴포넌트 리팩토링 절차는 아래 그림과 같다. 이러한 컴포넌트 리팩토링은 컴포넌트 클러스터링 원칙인 결합도가 적고, 결속력이 높은 상태의 컴포넌트로 바뀌게끔 그 목적을 두어야 한다. 2008. 11. 15.
반응형