규칙 8. 일급 컬렉션을 사용한다. 일급 컬렉션이란 컬렉션을 wrapping 하면서 wrapping 한 컬렉션 외 다른 멤버변수가 없는 상태를 일급 컬렉션이라 한다. 즉 이번 여덟 번 째 지침은 도메인 클래스를 컬렉션으로 감싸 처리해야 하는 경우 이를 일급 컬렉션으로 구현하라는 지침이다. 우리는 이전에 세 번째 지침인 '모든 문자열과 원시 자료구조를 포장하라'에서 기본 자료구조를 포장하며 얻는 이점에 대해 다뤄본 적이 있다. 여기선 '단수형 클래스'에 도메인적 요소를 부여는 것에 초점을 두었다면, 이번 여덟 번째 지침에서는 '복수형 클래스'에 도메인적 요소를 부여하여 단수형 클래스가 가질 수 없는 비즈니스 로직을 구현하도록 초점을 두는 것이다. 예시 먼저 일급 컬렉션이 무엇인지 예시를 통해알아보자. 다음..
규칙 7. 인스턴스 변수가 2개 이상인 클래스를 쓰지 않는다. 클래스의 인스턴스 변수의 수를 제한하라는 원칙이다. 여기서 말하는 인스턴스 변수는 원시타입, 문자열 또는 컬렉션을 포함한 기본 자료구조를 의미한다. 클래스에서 인스턴스 변수는 클래스가 관리하는 '상태'를 의미한다. 클래스의 상태는 정체성을 나타내는 요소로 상태가 많다는 것은 정체성 또한 많이 가지고 설계되었다는 것을 의미한다. 우리는 이전에 비슷한 문제를 해결한 경험이 있다. 세 번째 규칙인 '모든 원시값과 문자열을 포장한다.'에서 상태에 도메인적인 의미를 부여해보았다. 일곱 번째 지침에서는 의미를 가지는 상태를 효율적으로 관리하는 법을 이야기한다. 예시 다음과 같이 제목, 작가, 카테고리, 출판사, 가격의 속성을 가지는 Book 클래스가 있..
규칙 6. 모든 엔티티(클래스)를 작게 유지한다. 모든 엔티티의 크기를 작게 유지하라는 원칙이다. 여기서 말하는 엔티티는 클래스, 패키지를 포함해 비즈니스적 구분을 갖는 모든 단위를 의미한다. '50줄 이하의 클래스, 10개 이하의 패키지'를 작은 엔티티라고도 한다. 하지만 숫자에 연연하지 말고 최대한 클래스의 크기를 줄이려고 노력하면 된다고 생각한다. 클래스를 작게 유지하려면 어떻게 해야 할까? 클래스의 크기가 큰 이유는 하나의 클래스가 여러 개의 책임을 갖고 있기 때문일 것이다. 클래스가 하나의 책임만 갖는다면 그만큼 클래스의 크기도 줄어들 것이다. 똑같은 이야기를 SOLID의 첫 번째 원칙인 SRP (단일 책임 원칙)에서도 이야기하고 있다. 파일의 수가 늘어나는 것을 두려워하면 안 된다. 클래스의 ..
규칙 5. 줄여 쓰지 않는다. 클래스, 메서드, 변수 이름을 지을 때 줄여 쓰지 말라는 원칙이다. 이름을 줄이기 위해 'teamName'을 'tn'과 같이 약어를 사용하는 방식으로 줄이지 말라는 것이다. private String teamName; // o private String tn; // x 그렇다고 마냥 길이를 늘이라는 것은 아니다. 우리는 메서드나 변수의 이름을 최대한 줄일 필요가 있다. 굉장히 모순되는 것 같지만 그렇지 않다. 메서드의 책임을 분리한다. 메서드나 변수의 의미를 명확하게 하기 위해 임의로 축약하는 것은 안되지만, 하나의 메서드가 수행하는 일을 줄여 메서드의 이름을 줄이는 것이다. 다음과 같이 이름과 나이를 변경하는 메서드가 있다. public void updateNameAndA..
규칙 4. 한 줄에 점을 하나만 찍는다. 낯선 사람과는 대화하지 말고, 친구랑만 대화하라. 즉 한 줄에 점을 여러 개 찍지 말고 하나만 찍으라는 원칙이다. 점이 많다면 설계에 대한 고민을 다시 해볼 필요가 있다. 점을 찍는 행위는 필드나 메서드에서 인스턴스에 접근하려는 행위를 의미한다. 점의 개수가 많다는 것은 호출하려는 객체의 내부에 깊이 접근하겠다는 의도이고, 이는 호출자와 피 호줄자 사이에 강한 결합도가 형성되었다는 것을 의미한다. 예시 다음은 팀과 그 안에 멤버들이 속해있는 간단한 예시이다. Team 내부에 팀원들의 리스트인 members가 정의되어 있는 구조이다. 팀에 새로운 멤버를 등록하기 위해 getter로 members를 가져와 add() 메서드를 통해 등록 하였다. 여기서 우리의 친구는 ..
규칙 3. 모든 원시값과 문자열을 포장한다. int, long, String 등 모든 원시값과 문자열을 객체로 포장해 사용하라는 원칙이다. 프로그래밍에서 변수는 '상태'로 사용될 수 있다. 여기서 상태는 단순 '자료'가 아닌 '정보'이다. 값을 나타내는 것뿐만 아니라, 값에 대한 비즈니스적인 의미도 포함한다는 뜻이다. 예시 여기 학생들의 점수를 입력하는 프로그램이 있다고 가정하자. 점수를 담는 score 변수를 따로 포장하지 않고 사용하였다. 하지만 점수의 유효성을 검증하는 로직이 점수를 매기는 메서드 안에 들어있다. 같은 정보인 score를 여러 메서드에서 사용한다면 같은 유효성 검사 로직을 메서드마다 추가해야 하는 번거로움이 있다. public class GradingScore { private st..
규칙 2. else 예약어를 쓰지 않는다. 조건문을 활용할 때 else 예약어를 사용하지 말라는 원칙이다. switch-case 문 또한 사용하면 안 된다. else 예약어를 사용하지 않음으로 인해 한 메서드에 발생하는 분기문을 줄일 수 있다. 분기문이 많은 메서드는 많은 역할을 하는 메서드일 확률이 높다. 메서드를 분리하거나, 객체지향적인 구조를 통해 분기문을 줄일 수 있다. else는 '조건을 만족하지 않을 때'를 전재하고 시작한다. 조건을 만족하지 않는 모든 경우를 의미하기 때문에, 코드를 읽을 때 조건에 만족하는 경우와 만족하지 않는 경우 모두를 함께 생각해야 한다. 이는 오류가 날 확률도 높이며 코드의 가독성도 떨어뜨린다. 예시 다음은 간단한 계산기 예시이다. 아래 코드는 else 예약어를 사용..
객체지향 생활체조 원칙 객체지향 생활체조 원칙은 '마틴 파울러'의 '소트웍스 엔솔러지' 라는 책에서 다루고 있는 내용이다. 객체지향 프로그래밍을 잘하기 위한 9가지 기본 원칙을 제시하고 있다. 작동하는 코드가 아닌 깔끔하고 유지보수가 쉬운 코드를 작성하기 위해 객체지향 생활체조 원칙을 익히고 이를 소스코드에 적용해 보자! 규칙 1. 한 메서드에 오직 한 단계의 들여 쓰기만 허용한다. 들여 쓰기의 depth(단계)를 2 이상 허용하지 않는다는 지침이다. 예를 들어 while, for 반복문 안에 if 조건문이 있으면 들어 쓰기 단계가 2가 되는 것이다. 2중 반복문도 이에 포함된다. 메서드에 들여 쓰기를 한 단계만 허용하여 한 단락은 하나의 일만 하도록 설계할 수 있게된다. 로직이 잘게 쪼개질수록 메서드간..
