클래스 체계

• 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다.
• 변수 목록은 정적 공개 상수, 정적 비공개 변수, 비공개 인스턴수 변수 순으로 나온다.
• 변수 목록 다음에는 공개 함수가 나온다.
• 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다.

캡슐화

• 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다.
• 하지만 그 전에 비공개 상태를 유지하려고 노력해야 한다. 캡슐화를 풀어주는 것은 최후의 수단이다.

클래스는 작아야 한다!

• 함수와 마찬가지로 클래스는 작아야 한다!
• 단, 물리적인 행 수로 크기를 측정하는 함수와 달리 클래스는 책임이 작아야 한다.

단일 책임 원칙

단일 책임 원칙(SRP, Single Responsibility Principle)은 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 것이다.

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다!

응집도

• 클래스는 인스턴스 변수 수가 작아야 한다.
• 각 클래스 메소드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
• 일반적으로 메소드가 변수를 더 많이 사용할수록 응집도가 더 높다.
• 응집도가 높다는 것은 클래스에 속한 메소드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다.
• 즉, 몇몇 메소드만이 사용하는 인스턴스 변수가 생긴다면, 적절히 분리해 새로운 클래스로 쪼개주자.

응집도를 유지하면 작은 클래스 여럿이 나온다

• 큰 함수를 작은 함수 여럿으로 나누면 불행히도 응집력을 잃는다. 이때, 클래스가 응집력을 잃는다면 쪼개라!
• 그러면서 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.

변경하기 쉬운 클래스

• 대다수 시스템은 지속적연 변경이 가해지며 변경할 때마다 의도대로 동작하지 않을 위험이 따른다.
• 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

변경으로부터 격리

• 요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다.
• 시스템의 결합도를 낮추면 유연성과 재사용성이 높아지며, 잘 격리되어 있다는 의미기도 하다.
• 클래스는 상세한 구현이 아니라 추상화에 의존해야 한다. 이것을 DIP(Dependency Inversion Principle) 설계 원칙이라 한다. -> 인터페이스를 써라...?

상속 vs 인터페이스

스터디를 하던 중 인터페이스 말고 상속으로 쓰면 되지 않냐?? 라는 질문이 있었다. 듣고 보니 무슨 차이점이 있지??? 하게 되서 정리해보았다.

• 상속은 말그대로 부모 자식 간 상속이다.
• 인터페이스는 객체의 행위의 추상화(객체를 단순화)이다.
• 자바에서 상속은 단일 상속만 가능하지만 인터페이스는 다중 상속이 가능하다.
• 상속은 특정한 영역에 집중시킨다면 인터페이스는 유연하다!

정리

• 함수와 마찬가지로 클래스도 SRP 규칙을 지키며 쪼개주자.
• 응집도를 최대한 높이기 위해 쪼개는 것이 좋다!
• 변경에 대응할 수 있도록 인터페이스 형태의 추상화된 클래스를 만들자.

Reference

클린 코드: 애자일 소프트웨어 장인 정신 - 로버트 마틴 지음