오늘 TIL 3줄 요약

• 여러 기능을 가진 거대 클래스보다, 하나의 기능을 가진 여러 소규모 클래스를 조합하여 사용하라.

• 이상적인 시스템은 새 기능을 추가할 때 기존 코드를 변경하지 않는다.

• OOP 디자인패턴 공부하자

TIL (Today I Learned)

2024. 07.08

오늘 읽은 범위 - 10장. 클래스

• 책에서 기억하고 싶은 내용을 써보세요.

• 클래스는 작아야 한다.

-클래스가 포괄하는 범위가 넓어지면, 직관적으로 클래스를 설명하는 작명도 어려워진다.

-If, and, or, but 과 같은 전치사가 과도하게 붙는다면  클래스가 SRP원칙에 부합하지 않은 상태일 수 있다.

-클래스의 각 메서드가 같은 종류의 책임을 지도록 설계한다면 추상화를 더 쉽게 구현할 수 있다.

-“돌아가는 소프트웨어” 보다 중요한 것은 “깨끗하고 재사용 가능하며 유지보수가 용이한 소프트웨어”이다.

-프로젝트 규모가 커지면 논리의 복잡도가 높아진다. 이런 복잡성을 다루려면 체계적인 정리가 필수이며, 

소수의 큰 클래스들로 돌아가는 프로그램보다 SRP원칙에 기반한 작은 클래스 여러개로 돌아가는 프로그램이 압도적으로 유리하다.

• 응집도

-클래스 내의 인스턴스 변수들을 사용하는 메서드와 클래스의 ‘응집도’는 일정한 수준으로 유지되어야 한다.

-응집도가 높다는 것은 클래스 내 메서드와 변수가 논리적인 단위로 묶인다는 의미이다.

-대부분의 개발자들은 응집도 높은 클래스를 선호한다.

-거대 함수 하나를 여러개의 작은 함수로 나누다 보면 작은 클래스 여럿으로 쪼갤 기회가 생긴다.

• 변경하기 쉬운 클래스

-깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

-이상적인 시스템은 새 기능을 추가할 때 기존 코드를 변경하지 않는다.

• 핵심 요약, 소감

-하나의 기능을 수행하기 위한 거대 클래스, 거대 함수를 사용하기보다, 

각각의 클래스 내에서 인스턴스와 메서드들이 적절한 응집력을 유지하는 선에서 복수의 소규모 클래스로 나누어 프로그램을 구성하는 것이 좋다.

이는 프로젝트의 규모가 커지고, 복잡도가 높아졌을때 프로젝트를 안정적으로 확장하고 유지 보수할 수 있도록 해 준다.

-언뜻 보면 이 방식이 전체 코드 길이를 더 길게 만든다고 생각할 수 있지만, 그럼에도 SRP원칙에 따라 각 클래스에 명확히 구분되는 책임을 부여하고,

그 책임을 명확히 표현하는 변수명을 사용하며, 상황에 따라 유연하게 변경하여 사용하기 쉽도록 설계하는것이 우선시 되어야 한다. (그것이 OOP이니깐…)

• 더 알아볼 것

  -OOP 디자인 패턴

  -니꼬쌤의 디자인 패턴 관련 영상 => https://youtu.be/Pzy_MPfGixg?si=FY7JlEUFQIap1xkL

• 오늘의 슬랙