소프트웨어 악취를 제거하는 리펙토링 (Refactoring for software design smells)

3.4 다면적인 추상화

추상화에 할당된 책임이 둘 이상 있을 때 이런 악취가 발생한다. 

 

- 설계 구성 요소에서 일어나는 잦은 변경과 발생한 결함 수 사이에는 종종 강한 상관관계가 존재한다. 이것은 다면적인 추상화가 엄청난 결함으로 고통받기 쉽다는 사실을 의미한다. 다면적인 추상화는 설계 품질을 떨어뜨리므로 리팩토링을 거쳐 기술 부채를 해소하며 더 이상 쌓지 말아야 한다. 추상화에 여러 '책임이나 '측면'이 존재하므로, 이런 악취를 '다면적인 추상화'라 명명한다. 

 

주기적인 리팩토링을 통해 계속 쌓일 수 있는 technical debt 을 제거해야 한다. 제거하지 않으면 결국 design smell 이 발생할 수 밖에 없다. 

 

3 Abstraction smells

 

3.1 Missing abstraction

3.2 Imperative abstraction

3.3 Incomplete abstraction

3.4 Multifaceted abstaction

3.5 Unnecessary abstraction

 

3.6. Unutilized abstraction ( 사용하지 않는 추상화 : Unused class, Speculative generality )

-  추측, 또는 고객 요구 사항으로 사용하지 않는 코드를 삭제하지 않음으로써 동작에 의한 버그 추측 불가능 소스 코드 및 리소스 증가를 가져올 수 있다. 향후 코드 분석시에도 영향을 끼치게 된다. 

- Understandability, Reliablity 에 영향을 주게 된다. 

- 이러한 경우 삭제 또는 명시적으로 주석으로 언급한다.  ( Obsolete, Deprecated )

 

3.7 Duplicated abstraction ( 중복된 추상화 : )