클린코드, 클래스

클래스는 작아야 한다. (단위는 책임, 얼마나 많은 부분에 영향을 주는가?)

 

[클래스,, 추상화 잘 만들고 싶다.]

클래스부터 잘 만들기란 쉽지 않다는 것을 알고 있다 이 장을 읽으면서 느낀 점은

저자는 큰 맥락에서 순차적으로 설명해주는 느낌이었다.

그러면서 프로그래밍은 결국 유지하고 보수하면서 확장해나가면서 변화에 적응하고

발전해야 하기때문에 변경에 용이하도록 코드를 짜는 법을 익히는 느낌이었다.

 

책을 읽으면서 알고 싶었던 단어나 키워드 

 

소감 

- 확장성을 염두해두면서 프로그래밍하자

- 함수나 클래스나 작은 단위로 쪼개져 있을때 이해하기 쉽다.

- 소프트 웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다

 

참고 사항

SOLID 위키백과

S	SRP	단일 책임 원칙 (Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다.
O	OCP	개방-폐쇄 원칙 (Open/closed principle) “소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
L	LSP	리스코프 치환 원칙 (Liskov substitution principle) “프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
I	ISP	인터페이스 분리 원칙 (Interface segregation principle) “특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”[4]
D	DIP	의존관계 역전 원칙 (Dependency inversion principle) 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” [4] 의존성 주입은 이 원칙을 따르는 방법 중 하나다.