모든 코드는 이곳에 저장되어있다.
요구사항 분석
마크씨의 요구사항
- 은행 입출력 파일(CSV)을 읽고 분석해야 한다.
분석 사항
1. 입출금 내역의 총 수입과 지출은 얼마인가?
2. 특정 달엔 몇건의 입출력이 발생했는가?
3. 지출이 가장 높은 상위 10건은 무엇인가?
4. 돈을 가장 많이 소비하는 항목은 무엇인가?
KISS 원칙
KISS = keep it short and simple 원칙
KISS 원칙을 이용하여
public class BankStatementAnalyzerSimple {
private static final String RESOURCES = "src/main/resources/";
public static void main(final String[] args) throws Exception {
final Path path = Paths.get(RESOURCES + "bank-data-simple.csv");
final List<String> lines = Files.readAllLines(path);
double total = 0;
for(final String line: lines) {
String[] columns = line.split(",");
double amount = Double.parseDouble(columns[1]);
total += amount;
}
System.out.println("The total for all transactions is " + total);
}
}
이처럼 한 클래스에 다 때려박아버렸다.
유지보수성
위 코드는 과연 좋은 코드일까?
개인적인 생각은 아니요 였다.
위 코드는 한 클래스에 모든 기능이 구현되어있다.
-> 따라서 한 부분을 고치고 싶더라도 전체를 뜯어봐야 할 수 있다.
라는 이유였고 책도 비슷한 이야기를 했다.
<좋은 코드의 조건>
1. 특정 기능을 담당하는 코드 쉽게 찾을수 있어야 함
2. 어떤 기능을 수행하는 코드인지 이해하기 쉬워야 함
3. 새로운 기능 추가 및 기존 기능 제거가 쉬워야 함
4. 캡슐화, 즉 사용자에게 세부 구현 내용이 감춰져야 함
<나쁜 코드의 조건>
1. GOD class(하나의 거대한 클래스)
2. 코드 중복
<결론>
간결하게 구현하는 것도 무척 중요하지만
KISS 원칙을 남용하면 안된다.
전체 응용 프로그램의 설계 분석후, 한 문제를 여러 개별문제로 분리하는 과정이 중요SRP
단일 책임 원칙(SRP)는 한번에 하나의 책임만 진다는 소프트웨어 개발 지침이다.
한 클래스(or 매소드) 는 한가지 동작, 개념, 카테고리와 관련이 된다.
위 코드는
1. 입력 읽기
2. 파싱
3. 결과처리
4. 리포트
라는 4가지의 기능을 포괄하니 SRP원칙을 위해한다.
따라서 각 기능별로 클래스를 구현하여 쪼개준다.결합
겹합도는 한 기능이 다른 클래스에 얼마나 의존하고 있는지를 나타낸다.
이해하기 쉽게
파싱하는 작업을 클래스로 만들때 CSV에 대해서만 작동하도록 만들었다고 해보자.
하지만 중간에 CSV가 아닌 JSON 파일 이 들어온다면?
그냥 txt파일이 들어온다면?
해당 클래스를 전부 갈아엎어야하는 상황이 발생한다.
그렇기에 인터페이스를 활용하여 기능부와 구현부를 나눈다.
기능부는 인터페이스를 사용하여 내부 동작원리를 생각치 않고 기능을 쓴다.
구현부는 각 상황에 맞는 구현을 하여 동작하게한다.
학생