클래스 체계

1. 정적 공개 상수
2. 정적 비공개 변수
3. 비공개 인스턴스 변수
4. 공개 변수 (거의없음)
5. 공개 함수
6. 비공개 함수

캡슐화

• 캡슐화를 풀어주는 결정으 ㄴ언제나 최후의 수단이다.

클래스는 작아야한다!

• 클래스는 작아야 한다.
• 클래스가 맡은 책임을 센다.
• 클래스 이름은 해당 클래스 책임을 기술해야 한다. (작명은 클래스 크기를 줄이는 첫번째 관문이다.)
• Processor, Manager, Super 과같은 이름은 여러 책임을 맡았다는 증거다.
• 25단어 내외로 가능해야한다.(만일, 그리고, ~ 하며, 하지만 을 사용하지 않음)

단일 책임 원칙 (SRP)

• 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
• 큰 클래스 몇개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
• 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

응집도(Cohesion)

• 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
• 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다. (일반적으로 응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않다.)
• 함수를 작게, 매개변수 목록을 짧게 라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 새로운 클래스로 쪼개야 한다는 신호이다.

리팩토링

• 원래 프로그램의 정확한 동작을 검증하는 테스트 슈트를 작성
• 한 번에 하나씩 수 차례에 걸쳐 조금씩 코드를 변경한다.
• 코드를 변경할 때마다 테스트를 수행해 원래 프로그램과 동일하게 동작하는지 확인한다.
• 원래 프로그램을 정리한 결과 최종 플그램이 얻어진다.

변경하기 쉬운 클래스

• SRP 지원
• OCP 지원 (확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙)

변경으로부터 격리

• 테스트가 가능할 정도로 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
• 결합도를 최소로 줄이면 자연스럽게 DIP를 따르는 클래스가 나온다. DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

정리

• 이번 장에서는 클래스를 표현하는 방법부터 응집성을 높이고 결합도를 낮추는 설계기법들에 대해서 공부하였다. 소프트웨어를 개발하다 보면 초기에는 기능이 많지 않아 작은 단위의 클래스를 만들어 쉽게 관리되지만 오히려 서비스가 확장됨에 따라 SRP, OCP 등을 위반하는 경우가 많았던 것 같다 왜 그럴까 생각해 보면 초기 설계 시에는 책임을 분리하고 결합도를 낮추기 위해 고려를 많이 하지만 시스템이 확장됨에 따라 정확한 내용 파악과 문서화가 잘 돼있지 않으면 해당 내용이 누락되게 되고 또한 빠르게 개발한답시고 기존 인터페이스를 활용해서 추가만 하는 형태가 됐던 것 같다 그래서 자연스럽게 만능 클래스가 만들어지게 되고 이게 만능 클래슨지를 고려하지 않은 채 프로그램이 남아있게 된 것 같다. 그래서 이를 해결하기 위해 기능 구현을 위해 빠르게 추가하는 방법에는 동의하지만 거기서 멈추지 않고 리팩토링을 통해 계속 코드를 깨끗하게 유지하기 위해 책임을 나누고 의존성을 낮추려는 노력을 지속해야겠다는 생각을 하였다.