실전자바소프트웨어개발

코드유지보수성과 안티 패턴

1.코드 유지보수성

• 특정 기능을 담당하는 코드를 쉽게 찾을 수 있어야 한다.
• 코드가 어떤 일을 수행하는 지 쉽게 이해할 수 있어야 한다.
• 새로운 기능을 쉽게 추가하거나 기존 기능을 쉽게 제거할 수 있어야 한다.
• 캡슐화가 잘되어 있어야 한다. 즉 코드 사용자에게는 세부 구현 내용이 감춰져 있으므로 사용자가 쉽게 코드를 이해하고, 기능을 바꿀 수 있어야 한다.

1. 안티 패턴

• 한개의 거대한 갓 클래스(God Class) 때문에 코드를 이해하기 어렵다.
• 코드중복 때문에 코드가 불안정하고 변화에 쉽게 망가진다.
  • 갓클래스 : 한개의 파일에 모든 코드를 구현. 클래스의 목적 / 로직을 파악하기 어려워지며 수정하기 어려움. 이를 갓 클래스 안티패턴이라고 부름.

단일 책임 원칙

단일 책임 원칙(SRP) 쉽게 관리하고 유지보수하는 코드를 구현하는 데 도움을 주는 포괄적인 소프트웨어 개발 지침

• 한 클래스는 한 기능만 책임진다.
• 클래스가 바뀌어야 하는 이유는 오직 하나여야 한다.

응집도

응집도는 서로 어떻게 관련되어 있는지를 가리킨다. 정확히 말하자면 응지볻는 클래스나 메서드의 책임이 서로 얼마나 강하게 연결되어 있는지를 측정한다.

1. 클래스 수준 응집도

• 기능
• 정보
• 유틸리티
• 논리
• 순차
• 시간 그룹화하는 메서드의 관련성이 약하면 응집도가 낮아진다.

기능

기능이 비슷한 메서드를 그룹화 함께 사용하는 메서드를 그룹화하면 찾기도 쉽고 이해하기 쉬우므로 응집도를 높인다. 다만 기능 응집은 한 개의 메서드를 갖는 클래스를 너무 과도하게 만들려는 경향이 발생할 수 있다. 간단한 클래스를 과도하게 만들면 그만큼 생각해야 할 클래스가 많아지므로 코드가 장황해지고 복잡해진다.

정보

같은 데이터나 도메인 객체를 처리하는 메서드를 그룹화 정보 응집은 여러 기능을 그룹화하면서, 필요한 일부 기능을 포함하는 클래스 전체를 디펜던시로 추가한다는 약점이 있다.

유틸리티

때로는 관련성이 없는 메서드를 한 클래스로 포함시켜야 한다. 유틸리티 클래스의 사용은 낮은 응집도로 이어지므로 자제 해야한다. 메서드가 서로 연관성이 없으므로 클래스 전체의 기능을 추론하기 어려움.

논리

public class BankStatementFullParser { BankTransaction parseFromCSV(final String line) { // ... throw new UnsupportedOperationException(); } BankTransaction parseFromJSON(final String line) { // ... throw new UnsupportedOperationException(); } BankTransaction parseFromXML(final String line) { // ... throw new UnsupportedOperationException(); } }

CSV,Json,xml 의 자료를 파싱하는 코드를 구현한다는 가정 예제에서 네 개의 메서드는 파싱이라는 논리로 그룹화. 이렇게 그룹화 할 시 클래스는 4가지 책임을 갖게 되어, SRP를 위배함. 결과적으로 이방법을 권장하지 않음.

순차

입출력이 순차적으로 흐르는 것을 순차 응집이라고 함. 순차 응집은 여러 동작이 어떻게 함께 수행되는 지 쉽게 이해할 수 있다. 하지만 적용 시 한 클래스를 바꿔야 할 여러 이유가 존재하게 되어 SRP를 위배함.

시간

시간 응집 클래스는 시간과 관련된 연산을 그룹화 함.

<실전자바소프트웨어개발 p.38>

메서드 수준 응집도

메서드가 다양한 기능을 수행할 수록 메서드가 어떤 동작을 처리하는 지 이해하기가 점점 어려워진다. 일반적으로 클래스나 메서드 파라미터의 여러 필드를 바꾸는 if/else 블록이 여러개 포함되어 있다면, 이는 응집도에 문제가 있음. 응집도가 높은 더 작은 조각으로 메서드를 분리해야함.

결합도

결합도는 한 기능이 다른 클래스에 얼마나 의존하고 있는 지. 어떤 클래스를 구현하는 데 얼마나 많은 클래스를 참조했는 가로 설명할 수 있음.

<실전자바소프트웨어개발 p.41>

보통 코드를 구현할 때 결합도를 낮춰야 한다. 이는 코드의 다양한 컴포넌트가 내부와 세부 구현에 의존하지 않아야 함을 의미한다.