Clean Code: 클래스
1. 클래스 체계
-
자바의 경우 가장 먼저 변수 목록이 나온다.
-
static public 상수가 있다면 맨 처음에 나오고 다음으로 private 변수가 나오며, private 인스턴스 변수가 나온다.
-
공개 변수가 필요한 경우는 거의 없다.
-
변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 바로 다음에 넣는다.
-
캡슐화
테스트 코드에서 함수를 호출하거나 변수를 사용해야 한다면 그 함수, 변수를 protected로 선언하거나 패키지 전체로 공개할 수 있다.
하지만 그 전에 비공개 상태를 유지할 방법을 먼저 강구해야 한다. 캡슐화를 푸는 것은 최후의 결정이다.
2. 클래스는 작아야 한다
클래스는 작아야 하고, 더 작을 수록 좋은 클래스다. 여기서 작다는 기준은 클래스가 맡은 책임의 개수로 생각할 수 있다.
public class SuperDashboard extends JFrame implements MetaDataUser {
public Component getLastFocusedComponent();
public void setLastFocused(Component lastFocused);
public int getMajorVersionNumber();
public int getMinorVersionNumber();
public int getBuildNumber();
}
위 예시는 메서드가 5개밖에 없는 클래스이다. 그렇다면 작은 클래스일까?
그렇지 않다. 이유는 이 클래스가 맡은 책임의 개수를 보면 알 수 있다.
이 클래스는 마지막으로 포커스를 얻었던 컴포넌트에 접근하는 방법을 제공(1)하며, 버전과 빌드 번호를 추적하는 메커니즘을 제공(2)한다.
이미 2개 이상의 책임을 가진 것을 볼 수 있을 것이다.
따라서 이 클래스는 책임을 나누어 클래스를 더 작게 만들 수 있는데, 여기서는 버전 정보를 다루는 메서드를 Version 클래스로 분리할 수 있다.
-
단일 책임 원칙(SRP)
클래스나 모듈을 변경할 이유(책임)가 단 하나여야 한다는 원칙이다. 따라서 클래스는 변경할 이유가 하나여야 한다.
한편 SRP를 통해 클래스를 나누게 되면 수많은 클래스를 넘나들어야 하고, 큰 그림을 이해하기 어렵다고 생각할 수 있다.
하지만 오히려 시스템이 복잡해질수록 다목적 클래스는 당장 알 필요가 없는 사실까지 강제하여 이해를 방해하는 반면, 작은 클래스를 체계적으로 정리하면 차후에 변경이 필요할 때도 직접 영향을 미치는 컴포넌트만 변경하면 되므로 편리하다. -
응집도
클래스는 인스턴스 변수 수가 적어야 한다. 메서드가 변수를 더 많이 사용할수록 메서드와 클래스의 응집도가 높다.
그런데 '함수를 작게, 매개변수 목록을 짧게' 전략을 따르다 보면 일부 메서드만이 사용하는 인스턴스 변수가 많아진다.
이는 클래스를 쪼개야 한다는 신호로, 클래스의 응집도가 높아지도록 변수와 메서드를 새로운 클래스로 분리해야 한다.
3. 변경하기 쉬운 클래스
깨끗한 클래스는 SRP를 지원할 뿐만아니라 OCP(개방-폐쇄 원칙)도 지원한다. 파생 클래스를 생성하여 새 기능을 추가할 수 있어 개방적인 한편 다른 클래스는 닫아서 수정에는 폐쇄적이 된다. 이를 통해 기능을 추가하더라도 시스템이 확장될 뿐, 기존 코드는 변경되지 않는다.
Author And Source
이 문제에 관하여(Clean Code: 클래스), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@jiffydev/Clean-Code-클래스저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)