- 클래스 체계
- 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다.
- 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다.
- 클래스는 작아야 한다.
- 클래스를 한 문장으로 설명할 때 “만일(if), 그리고(and), 하며(or), 하지만(but)”가 들어가면 그 클래스에 책임이 너무 많다는 의미이다. → 단일 책임 클래스 여러 개로 분리할 필요가 있음.
- 단일책임원칙 (SRP) : 클래스의 책임은 하나, 클래스를 바꾸려는 이유는 클래스 당 하나
덧셈 로직을 바꾸고 싶다 → sum 클래스를 고친다 (O)
작은 클래스 여러개를 만들어서 한 곳에 몰아 넣지 말고 이름과 기능에 따라 명확한 컴포넌트를 나눠 넣기덧셈과 뺄셈 로직을 바꾸고 싶다 → 계산기 로직을 바꾼다 (X)
- 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 만약 몇 개의 메서드만이 인스턴스 변수를 사용하면 메서드를 분리해야 한다.
- 변경하기 쉬운 클래스
- 개방폐쇄원칙 (OCP) : 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드는 변경하지 않는다. 다른 클래스는 막아두어 내가 수정하려는 것만 나에게 보여야 한다. 인터페이스를 만들어 메서드를 재정의해 기본 코드 안건들고 코드만 추가
update 문을 추가할 때 기존 클래스를 변경할 필요가 전혀 없다는 사실 역시 중요하다! update 문을 만드는 논리는 새 클래스 UpdateSql에서 Sql 클래스를 상속받아 update메서드를 재정의한다. update 문을 지원해도 다른 코드가 망가질 염려는 전혀 없다. (@Roxy)
- 변경으로부터 격리 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. (테스트 코드 작성이 어려워짐) 의존역전법칙 : 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현부를 추상화한다.
- 개방폐쇄원칙 (OCP) : 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드는 변경하지 않는다. 다른 클래스는 막아두어 내가 수정하려는 것만 나에게 보여야 한다. 인터페이스를 만들어 메서드를 재정의해 기본 코드 안건들고 코드만 추가
