개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
클래스는 작아야 한다. 작은 클래스는 책임이 하나이어야 한다.
클래스의 인스턴스 변수를 최소화아여 응집도를 높이자.
클래스는 새 기능에 개방적인 동시에 수정에는 폐쇠적이여야 한다.
TIL (Today I Learned) 날짜
20220308
오늘 읽은 범위
10장 클래스
책에서 기억하고 싶은 내용을 써보세요.
캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이루어진 시스템이 더 바람직하다.
서랍을 어떻게 관리하는게 좋을지 생각해봅시다. 작은서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 큰 서럽에 모두를 던져 놓고 싶은가?
이러한 복잡성을 다루려면 체계적인 정리가 필요하다.
(규모가 어느 수준에 이르는 시스템은 논리가 많고 복잡하다.)
응집도 ⬆️
클래스는 인스턴스 변수 수가 작아야한다.
일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도 높다.
변경하기 쉬운 클래스
깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반한 위험을 낮춘다.
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
클래스는 가능한 작게 만들어야 한다. 알고 있다 하지만 쉽게 까먹게 된다. 시간이 촉박하다는 이유가 가장 컷다. 무엇보다 개발 완료로 QA진행 중인데 도중에 리펙터링을 진행한다는건 다시 QA를 해야한다는 의미이다. 바로 내일부터 적용하기는 어렵겠지만, 좋은 클래스의 기준이 무엇인지 알수 있는 기준이 되었다.
큰 클래스를 지지하는 분이 계신다. 이리저리 왔다갔다 하는게 더 헷갈린다고 했다. 오히려 설득당했고, 추가 작업이 들어갈 때 마다 클래스 안에 새로운 메서드를 추가함으로 클래스를 더 키웠다.
하지만 오늘 책을 통해 큰 클래스가 좋지 않다는 이유를 분명히 알수 있었다.
큰 서럽랍에 다 때려넣는것보다는 작은 서랍 여러개로 분리되어 확인 하는 것이 더 효율적이라는걸..
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
SOAP 서비스 : simple object access protocal로 html, https, smtp 등을 통해 xml 기반의 메시지를 네트워크 상에서 교환하는 프로토콜이다.
https://ko.wikipedia.org/wiki/SOAP
오늘 읽은 다른사람의 TIL
roghabo 님의 https://nomadcoders.co/community/thread/3418