클린코드

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경을 써도 좀더 높은 차원까지 신경을 쓰지 않으면 클린코드를 얻기 어렵다.

정적 공개 상수 그담으로 정적 비공개 변수 이어서 비공개 인스턴스 변수 공개 변수가 필요한 경우는 거의 없다.

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 하는 법칙도 없다
때로는 변수나 유틸리티 함수를 protrected로 선언해 테스트 코드의 접근을 허용하기도 한다.

캡슐화를 풀어주는 결정은 언제나 최후의 수단이여야 한다.

클래스를 만들 때 첫번째 규칙은 크기다. 클래스는 작아야 한다. 두번째 규칙도 크기다. 더작아야한다.

클래스의 척도는 클래스가 맡은 책임을 센다.

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

규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이러한 복잡성을 다루려면 체계적인 정리가 필수적이다.

클래스는 인스턴스 변수 수가 적어야 된다. 각 클래스 메소드는 클래스 인스턴스 변수를 하나 이상 사용해야한다.

일반적으로 메소드가 변수를 더많이 사용할수록 응집도가 높다.

함수는 작게 매개변수 목록은 짧게 라는 전략을 따르다 보면 몇몇 메소드만이 사용하는 인스턴스 변수수가 많아 진다 이때가 클래스를 쪼개야할때이다.

큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다.

변수 4개를 새함수에 인자로 넘기는것이 좋을까? 인스턴스 변수로 승격을 시키면 클래스의 응집도가 떨어진다. 몇몇함수만 사용하기 때문에

이렇게 되면 클래스를 나눌때이다.

클래스를 세분화 하고 단일책임원칙을 따르고 개방 패쇄원칙을 따라서 클래스를 작성해야 한다.

요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다. 객체지향 프로그래밍 입문에서 우리는 구상 클래스와 추상 클래스가 있다고 배웠다.

시스템 결합도를 낮추면 유연성과 재사용성도 더 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 또한 변경으로부터
잘 격리돼있다는 의미이다.

이렇게 결합도를 최소한으로 줄이면 의존성주입을 따르는 클래스가 나온다

참조