getter/setter/property를 쓰지 않는다 도메인 오브젝트로 설계한 Entity 또는 VO 클래스에는 getter/setter/property 사용을 지양해 상태노출을 최소화 하라는 지침이다. 숨은 의미 객체지향 프로그래밍의 핵심 개념 중 캡슐화를 지키면서 객체에 메시지를 보내 스스로 상태에 대한 처리로직을 수행하도록 하라는 의미이다. 이 지침은 데이터 전달을 목적으로 하는 DTO나 비즈니스 플로우 실행을 목적으로 하는 컨트롤러•서비스 유형의 무상태 클래스를 대상으로 하지 않는다. 객체에 메시지를 전달해라 객체지향 프로그래밍은 객체의 '역할과 책임' 이라는 핵심 가치를 잘 유지할 때 그 의미가 살아난다. 이 역할과 책임의 대한 의의는 객체가 자신의 상태, 즉 정보에 대한 처리책임을 자신 스스..
일급 컬렉션 컬렉션은 wrapping 하면서 컬렉션 외의 다른 필드를 가지고 있지 않은 클래스를 일급 컬렉션 이라고 한다. 이번 여덟번째 지침에서는 도메인 클래스를 컬렉션으로 감싸 처리하는 경우, 이를 일급 컬렉션으로 구현하라는 가이드를 제시한다. 숨은 의미 컬렉션은 '무리', '모음' 이라는 의미를 갖는다. 클래스 인스턴스들을 컬렉션 자료구조로 감싸게 되면 구조로부터 도메인 로직을 얻을 수 있다. 인스턴스들의 집합에서 특정 인스턴스를 찾아내거나, 정렬을 할 수도 있고, 특정한 패턴으로 자료구조의 내용을 변형하는 것도 가능하다. 일급컬렉션은 인스턴스의 집합을 '복수형 클래스'로 정의함으로써 단수형 클래스가 가질 수 없는 비즈니스 로직을 구현할 수 있도록 도와주는 도메인 설계라고 볼 수 있다. 예시 고객이..
2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다 클래스의 인스턴수 변수를 제한하라는 지침이다. 여기서의 인스턴수 변수는 원시타입, 또는 컬렉션과 같이 기본 또는 자료구조형의 변수를 의미한다. 숨은 의미 클래스의 인스턴수 변수는 클래스가 관리하는 '상태' 를 의미한다. 클래스의 상태는 클래스의 정체성을 나타내는 요소이다. 이 상태의 종류가 많다는 것은 클래스가 여러 종류의 정체성을 가지고 설계되었다는 것을 의미한다. 이 지침은 원칙의 세 번째 지침인 '모든 원시값과 문자열을 포장한다' 의 내용과 통한다. 세 번째 지침은 상태에 도메인적 의미를 부여하라는 가이드라고 할 수 있다. 이 일곱번째 지침에서는 의미를 갖는 상태를 어떻게 관리하는 것이 좋은지에 대한 내용을 이야기하고 있다. 예시 class N..
모든 엔티티를 작게 유지한다 이 원칙에서 칭하는 엔티티는 클래스, 패키지를 통틀어 업무적 구분을 갖는 단위를 의미한다. '작은 엔티티' 라고 판단할 수 있는 대략적인 기준은 다음과 같다. 50줄 이하의 클래스 10개 이하의 파일을 갖는 패키지 숨은 의미 엔티티를 작성할 때 하나의 목적을 염두하고 설계하라는 의미이다. SOLID 원칙중 '단일 책임 원칙' 과도 상통한다. 먼저 클래스의 크기를 줄여 분리하기 시작하면, 작은 역할을 하게 될 것이다. 이 때 작은 역할을 통해 이루려는 하나의 목적을 도출할 수 있다. 그 목적을 이루기 위한 클래스들을 모아 패키지로 구성하면 된다. 패키지와 파일이 많은 것은 나쁜게 아니다 이 원칙을 지키기 어려운 가장 큰 원인은, 패키지를 새로 만들고 파일을 새로 만드는 행위에 ..
줄여쓰지 않는다 클래스, 메소드, 변수의 명명시에 축약을 하지 말자는 규칙이다. 숨은 의미 왜 줄여쓰지 말아야 할까? 이 질문의 답은 '왜 줄이려고 하는가?' 라는 질문에서 시작할 수 있다. 축약을 하려는 이유는 간단하다. 이름이 너무 길고 복잡하기 때문이다. 복잡하고 긴 이름을 줄이기 위해 가장 먼저 단어의 길이를 줄이는 약어를 사용한다. 그러나 이 방법은 표현의 방법을 바꾸어 프로젝트에서 용어의 일관성과 명확한 의미전달에 문제를 야기할 수 있다. 긴 이름을 줄여야 하는 이유는 단어가 가진 의미를 줄이는 데 있다. 일반적으로 이름이 길어진다는 것은 해당 변수, 메소드, 클래스에 많은 책임이 부여되어 있다는 것을 의미한다. 이번 규칙의 숨은 의미는 이름이 길어지면, 설계를 고민해보라는 뜻을 담고 있다. ..
한 줄에 점을 하나만 찍는다 코드를 작성할 때 한 라인에 점이 여러 개 생기면, 설계에 대한 고민을 해보라는 지침이다. 숨은 의미 단순히 라인에 존재하는 점의 개수를 헤아려 줄이라는 의미는 아니다. 점을 찍는 행위는 필드나 메소드를 통해 인스턴스에 접근하는 행위를 의미한다. 점의 개수가 많다는 것은 대상 객체의 내부에 깊이 접근하겠다는 의도를 드러내게 되고, 이는 호출자와 피호출자 사이에 강한 결합도가 형성되었다는 것을 의미한다. 예시 public class PaymentService { private MemberRepository memberRepository; public void payment(Long memberId, int accountSequenceNumber, Statement stateme..
모든 원시값과 문자열을 포장한다 int, long, String 과 같은 원시타입, 문자열 변수를 객체로 포장해 사용하라는 지침이다. 숨은 의미 프로그래밍에서 변수는 '상태' 로 쓰일 수 있다. 상태는 '자료'가 아니라 '정보'다. 단순히 값을 나타내는 것 뿐 아니라, 비즈니스적인 의미를 함께 표현해준다. 이렇게 업무적 의미를 갖는 변수를 객체로 포장해 사용하면 얻는 이점이 많다. 예시 public class EvaluateService { private static final int MIN_CREDIT_SCORE = 0; private static final int MAX_CREDIT_SCORE = 1000; public void evaluateCustomerCreditRate(int score) { ..
else 예약어를 쓰지 않는다 말 그대로 else 예약어를 사용하지 않고 코드를 작성해보라는 지침이다. switch/case 문을 사용하는 것도 허용하지 않는다. 숨은 의미 이 원칙의 제시의도는 한 메소드에서 발생하는 분기문을 줄이자는 것이다. 분기문을 많이 가지고 있는 메소드는 많은 기능을 가지고 있을 확률이 높다. 메소드를 분리하거나, 객체지향적인 구조를 적용해 분기문을 줄일 수 있다. 이는 결국 설계관점에서의 개선을 의미한다. else 키워드는 '조건을 만족하지 않을 때' 를 전제하고 시작한다. 가독성이 떨어질 수 밖에 없다. if 조건을 만족하지 않는 모든 경우 를 의미하기 때문에, 코드를 읽을 때 양 쪽을 함께 생각해야 한다. 오류가 발생할 확률도 높다. 예시 public String getPr..
객체지향 생활체조 원칙 객체지향 생활체조 원칙은 소트웍스 엔솔러지 라는 책에서 다루고 있는 내용이다. 객체지향 프로그래밍을 잘 하기 위한 9가지 기본원칙을 제시하고 있다. 원칙의 제목을 처음 접하는 사람들은 생소하거나 다소 거부감이 들 수도 있을 것 같다. 그러나 이 책에서 주장하는 9가지 원칙에 숨은 의미를 곰곰히 생각해보고 소스에 적용하면, 어느새 깔끔한 구조의 객체지향 설계가 완성되는 것을 경험할 수 있다. 규칙 1. 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다 들여쓰기의 depth를 2 이상으로 두지 말라는 지침이다. 예를 들어서 for 또는 while 반목문 안에 if문이 있으면 indent depth가 2인 코드가 된다. 반복문 안에 반복문이 존재하는 것도 마찬가지다. 숨은 의미..
매직넘버 / 리터럴 사용 매직넘버/리터럴 이란 프로그래밍에서 비즈니스적 의미를 가진 숫자나 문자를 그대로 표현한 것을 칭한다. public class BankingAccount { private BigDecimal depositAmount; public String productName(String productCode) { if ("1".equals(productCode)) { return "입출금통장"; } if ("2".equals(productCode)) { return "모임통장"; } throw new IllegalArgumentException("상품이 존재하지 않습니다."); } public void makeDeposit(BigDecimal depositAmount) { if (deposi..
- Total
- Today
- Yesterday