[실전 자바 소프트웨어 개발]CH2 입출금 내역 분석기

목표

• 좋은 소프트웨어 개발의 기반은 무엇인가?
• 한개의 클래스로 구현 후 프로젝트를 진행하면서 바뀌는 요구사항이나 유지보수에 대응하며 기존 구조의 한계가 무엇인지 확인한다.
• 단일 책임의 원칙이란 (SRP)
• 응집도와 결합도의 특징

KISS 원칙

Keep it small and simple. Keep it short and simple

큰 프로젝트를 단순하게 디자인 하지 못하고 복잡하게 구현 한다는 것은 프로젝트를 제대로 이해하지 못했다는 증거이다. 프로젝트가 진행되기 전에 최대한 기반 배경과 추진되는 목적자체를 이해하고 어떻게 구현을 단순화하고 알기쉽게 설계할 수 있을지 회의를 개선해야한다.

 

final 변수

final로 표시하면 어떤 객체의 상태가 바뀔 수 있고, 어떤 객체의 상태가 바뀔 수 없는지 명확하게 구분할 수 있다.

 

아래 처럼 선언하게 되면 해당 변수들은 객체 내에서 변경되면 안된다는 것을 강조 할 수 있다.

public BankTransaction(final LocalDate date, final double amount, final String description) {
}

 

코드 유지보수성

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

단일 책임 원칙

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

 

클래스가 바뀌어야 하는 이유는 오직 하나여야 한다.

아래 예제에서는 책 객체를 예로 들며 책에 지금까지 읽은 페이지를 저장하는 기능, 책을 다음페이지로 넘기는 기능이 있다고 할 때, 지금까지 읽은 페이지를 저장하는 기능을 분리 함으로써 단일 책임 원칙을 달성할 수 있다고 소개 하고 있다. 

 

이전 코드에서 저장기능의 변경 이유로 책이 바뀔 수도 있고, 책을 다음페이지로 넘기는 기능의 변경 이유로 책이 변경 될 수도 있었는데, 책이 하나의 책임만 지게 함으로써 이것을 줄이는 것이다.

 

SOLID: 1부 - 단일 책임 원칙

응집도

응집도는 모듈에 포함된 내부 요소들이 하나의 책임/목적을 위해 연결되어있는 연관된 정도 이다.

 

• 모듈이 하나의 목적을 수행하는 요소들간의 연관성 척도
• 모듈 내부의 기능적인 응집 정도를 나타냄
• 높을 수록 좋다

 

클래스나 메서드의 책임이 서로 얼마나 강하게 연결되어 있는지를 측정한다.

실무에서는 일반적으로 다음과 같은 여섯 가지 방법으로 그룹화한다.

• 기능
• 정보
• 유틸리티
• 논리
• 순차
• 시간

그룹화하는 메서드의 관련성이 약하면 응집도가 낮아진다.

 

메서드가 다양한 기능을 수행할 수록 메서드가 어떤 동작을 하는지 이해하기가 점점 어려워진다. 즉 메서드가 연관이 없는 여러일을 처리한다면 응집도가 낮아진다. 응집도가 낮은 메서드는 여러 책임을 포함하기 때문에 책임을 테스트하기가 어렵다. if/else 블록이 많다면 이는 응집도에 문제가 있음을 의미한다.

 

결합도

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

 

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

 

인터페이스를 사용하여 컴포넌트간의 결합도를 제거 할 수 있다.

 

시계가 디지털 시계이건, 아날로그 시계이건 관계 없이 우리는 시계를 보고 시간을 알 수 있다.

내부 구현은 알 필요없이 인터페이스만 알면 되기 때문이다.

 

 

Chapter2 브랜치 참고하기

DWL5/Real-World-Software-Development