Justin의 개발 로그

보호되어 있는 글입니다.

Never Have Common Affixes정의여러 변수나 필드가 동일한 prefix 또는 suffix를 반복해서 갖고 있다면 별도의 개념으로 묶어야 한다.예를 들어:userNameuserAgeuserAddressuserPhone 처럼 user라는 공통 접두사가 반복된다면 User라는 객체가 빠져 있을 가능성이 있다.설명이름에 반복되는 공통 부분은 개발자가 코드만으로 숨겨진 데이터 구조를 표현하고 있다는 신호다.스멜Data ClumpPrimitive Obsession반복되는 변수명 prefix/suffix여러 함수가 항상 같은 변수 묶음을 함께 전달의도이름 속에 숨어 있는 도메인 개념을 객체로 승격하고 데이터를 캡슐화한다.참조6.2.1 Rule: Never Have Common Affixes6.2.3 ..

Do Not Use Getters or Setters정의객체 내부 데이터를 가져와 외부에서 처리하거나 외부에서 직접 값을 설정하는 getter/setter 사용을 피한다.설명객체에서 데이터를 꺼내 외부 코드가 판단하고 처리하면 실제 비즈니스 로직이 데이터가 있는 객체가 아니라 다른 곳으로 흩어진다.즉,객체 → 데이터 꺼내기 → 외부에서 계산 → 다시 객체 변경보다는객체에게 원하는 행동을 요청하는 구조를 선호한다.스멜Feature EnvyAnemic Domain ModelData ClassTell 대신 Ask가 많은 코드getter를 연속적으로 호출하는 코드의도데이터와 그 데이터를 다루는 행동을 같은 객체에 위치시켜 캡슐화를 강화한다.참조6.1.1 Rule: Do Not Use Getters or Sett..

정의인터페이스에 구현 클래스가 하나밖에 없다면 그 인터페이스가 정말 필요한지 의심한다.설명미래의 확장 가능성을 예상해서 미리 인터페이스를 만들면 실제 필요가 없는 추상화 계층이 생길 수 있다.책은 먼저 구체적인 구현을 만들고, 실제로 두 번째 구현이 등장하면서 공통 구조가 확인될 때 인터페이스를 추출하는 방향을 강조한다.스멜Speculative Generality불필요한 인터페이스구현체가 하나뿐인 추상화미래를 예상한 설계의도필요해진 뒤에 추상화하여 과도한 일반화를 피한다.참조5.4.3 Rule: No Interface With Only One Implementation5.4.4 Extract Interface from Implementation5.4.2 Introduce Strategy Pattern정의..

5.3.2 규칙: 순수한 조건을 사용한다Use Pure Conditions정의조건식은 부수효과(side effect)가 없는 순수한 표현식으로 만든다.설명조건을 평가하는 과정에서 객체의 상태를 변경하거나 외부 동작이 발생하면 조건식을 이동·결합·단순화하기 어려워진다.순수한 조건이라면 논리식을 Boolean algebra처럼 안전하게 변형할 수 있다.스멜조건 평가 중 상태 변경함수 호출 결과에 따라 상태가 달라짐복잡한 Boolean 조건조건식의 실행 순서에 의존의도조건을 자유롭게 결합·분리·재배열·단순화할 수 있도록 한다.참조5.3.1 Using Arithmetic Rules for Conditions5.3.2 Rule: Use Pure Conditions5.3.3 Applying Condition Ari..

4.3.2 규칙: 인터페이스로부터만 상속한다Only Inherit from Interfaces정의구현을 재사용하기 위해 클래스를 상속하지 않는다.상속이 필요하다면 구현이 아닌 인터페이스의 계약만 상속한다.클래스 상속은 부모 클래스의 구현과 자식 클래스를 강하게 결합시키기 때문이다.정의상속보다 인터페이스를 구현하는 방식을 선호한다.설명구현 상속은 부모 클래스의 내부 구조와 자식 클래스 사이에 강한 결합을 만든다. 부모의 구현 변경이 자식에게 예상하지 못한 영향을 미칠 수 있다.스멜Implementation Inheritance : 상속 구현Fragile Base Class부모 클래스 구현에 강하게 의존하는 자식깊은 상속 계층의도구현보다 계약에 의존하게 하여 결합도를 낮추고 변경에 유연한 구조를 만든다.참조..

4.2.4 규칙: switch를 사용하지 않는다Never Use Switch정의가능하면 switch를 사용하지 않는다.switch가 타입에 따라 서로 다른 행동을 선택하고 있다면 그 행동을 각 타입의 객체로 이동할 수 있는지 확인한다.설명타입이나 상태 값에 따라 switch가 행동을 선택하기 시작하면 새로운 타입이 추가될 때마다 기존 switch들을 찾아 수정해야 하는 구조가 만들어지기 쉽다.책에서는 컴파일러가 exhaustiveness를 검증할 수 있고 각 case가 명확히 종료되는 형태 등 제한적인 switch 사용은 별도로 다룬다.스멜Switch StatementsType Code여러 위치에 동일한 switch새로운 타입 추가 시 기존 코드의 다수 수정의도타입별 행동을 각 객체에 배치하여 다형성(p..

4.1.1 규칙: if-else를 사용하지 않는다Never Use If With Else정의가능하면 if 와 else를 함께 사용하지 않는다.특히 타입에 따라 다른 행동을 선택하는 if-else는 타입 코드가 객체로 표현되지 못하고 있다는 신호다.다형성을 사용해서 if... else를 객체 스스로 판단(처리)하도록 위임한다.설명if/else는 하나의 함수가 서로 다른 두 행동을 책임지게 만드는 경우가 많다. 특히 어떤 타입 코드나 상태에 따라 행동을 선택한다면 객체나 클래스로 행동을 이동시키는 편이 더 나은 구조가 될 수 있다.단, 책에서는 자신이 제어하지 못하는 외부 데이터 타입 등을 검사하는 경우 같은 예외 상황을 인정한다.스멜Conditional Complexity타입 코드에 따른 분기같은 조건이..