[CleanCode] 객체와 메서드 그리고 클래스

안녕하세요~

지난 포스팅에서는 클린코드의 개념에 대하여 알아보았죠?

이번 포스팅에서는 객체와 메서드 그리고 클래스를 생성할 때 주의할 점에 대하여 정리해보았습니다.

네이밍부터 클래스 생성 법칙까지 정리하였으니 도움이 되길 바랍니다!

 

네이밍

의미 있는 이름
변수 및 메서드의 이름은 의미를 담아 짓는다. 

접두어 사용 자제
아직까지 멤버 변수 앞에는 m을 붙이는 등 접두어를 사용하는 경우가 종종 있다.
접두어 사용은 옛날 방식의 코딩!

클래스와 메서드 네이밍을 분리한다
클래스 이름은 명사로 , 메서드 이름은 동사로 명명한다.

 

메서드

작게 만들어라
Spark의 Source Code는 모든 함수가 2-3줄로 이루어져 있다

조건문 내부에 들어가는 함수는 되도록 한 줄로 만들어라

하나의 함수는 한 가지 기능만 한다

함수의 인수는 0개가 이상적이다
함수의 인수는 0개가 이상적이며 4개 이상은 되도록 사용하지 말 것

플래그 인수 쓰지 마라
플래그 인수 사용은 함수가 여러 가지 기능을 한다고 자랑하는 꼴이다

함수에서 부수효과를 일으키지 마라
하나의 함수는 하나의 역할만을 한다. 부수 효과를 일으키는 함수는 좋지 않다.

변수 선언은 사용하는 곳 가까이서 선언
서로 종속되는 함수는 세로로 가까이 배치한다.

행의 길이는 가로 세로 모두 짧게
행의 가로길이뿐만 아니라 세로 길이도 신경 쓰자.

 

객체와 자료구조

객체와 자료구조 생성 시의 원칙은 다음과 같다.

자료 추상화
추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 한다.

디미터 법칙
자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙으로 객체는 조회 함수로 내부 구조를 변경해서는 안된다는 의미.

기차 충돌
여러 객체가 한 줄로 이어진 기차처럼 보인다. hana.getHanaInfo().getBodyInfo().getHigth() 같은 형식.

DTO
자료 전달 객체로 공개 변수만 있고 함수가 없는 클래스를 의미한다.

 

클래스

클래스 체계
변수목록의 순서는 다음과 같다.
static public -> static private -> private
공개 변수가 필요한 경우는 거의 없다. 없어야 한다!
다음에는 공개 함수가 나온다.

비공개 함수는 자신을 호출하는 공개함수 직후에 넣는다.
추상화 단계가 순차적으로 내려가는 것이다.

캡슐화
변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 때로는 변수나 유틸함수를 protected로 선언, 테스트 코드에 접근을 허용하기도 한다.
하지만 그전에 비공개 상태를 유지할 방법을 강구하자~ 캡슐화를 풀어주는 것은 언제나 최후의 수단이다.

클래스는 작아야 한다
클래스를 만들 때 첫 번째 규칙은 크기! 두 번째 규칙도 크기!
그럼 얼마나 작아야 할까? 다섯개?
메서드 수가 적어도 책임이 많다면 괜찮지 않다!
클래스 이름은 해당 클래스의 책임을 기술해야 하는데 간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 크기 때문이다.
클래스의 책임이 너무 많아 모호한 것!
클래스 명은 if , and , or , but 을 사용하지 않고 25 단어 내외로 작성해야 한다.

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

'깨끗하고 체계적인 소프트웨어' 보다 '돌아가는 소프트웨어'에 초점을 맞춘다면 SRP를 무시하기 십상이다.
SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다.
규모가 어느 정도 수준에 이르는 시스템은 논리가 많고도 복잡한데 이런 복잡성을 다루려면 체계적인 정리가 필수다!
큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이루어진 시스템이 더 바람직하다.
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

응집도
클래스는 인스턴스 변수 수가 적어야 한다.
일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다.
모든 인스턴스 변수를 메서드마다 다용하는 클래스는 응집도가 가장 높다.

그렇지만 이런 클래스는 가능하지도 바람직하지도 않다.
응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하고 논리적인 단위로 묶인다는 의미이기 때문!
'함수를 작게, 매개변수 목록을 짧게'라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아지는데 이는 새로운 클래스로 쪼개야 한다는 신호이다!
응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

응집도를 유지하면 작은 클래스 여럿이 나온다
큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다.
클래스가 응집력을 잃는다면 쪼개라!
함수 또한 마찬가지.

큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다.
그러면서 프로그램은 체계적이고 투명해질 수 있다.