적절한 책무를 생각하고 강한 결합을 방지하려면, 클래스와 메서드에 적절한 이름을 붙여야 함가장 기본적인 방법은 목적 중심 이름 설계(이름에서 목적과 의도를 읽고 이해할 수 있게 설계하는것)10.1 악마를 불러들이는 이름관심사 분리 : 관심사(유즈 케이스, 목적, 역할)에 따라 분리하자관심사에 맞는 이름 붙이기 → 비즈니스 목적에 따라 이름을 붙이기10.2 이름 설계하기 - 목적 중심 이름 설계프로그래밍에서 이름은 가독성을 높일 뿐만 아니라 비즈니스 목적에 맞게 이름을 붙이는 것은 결합이 느슨하고 응집도가 높은 구조를 만드는데 중요한 역할을 함목적 중심 이름 설계하기최대한 구체적이고, 의미 범위가 좁고, 특화된 이름 선택하기존재가 아니라 목적을 기반으로 하는 이름 생각하기존재 기반 목적 기반주소발송지, 배..

9.1 데드 코드데드 코드 : 실행되지 않는 조건 내부에 있는 코드 → 발견 즉시 제거9.2 YAGNI 원칙YAGNI : You Aren’t Gonna Need IT (필요 없는 기능을 만들지 말라!)9.3 매직 넘버설명이 없는 숫자 → 상수를 활용하자9.4 문자열 자료형에 대한 집착9.5 전역 변수거대 데이터 클래스도 여러 곳에서 참조하기 때문에 전역 변수와 같은 성질을 가질 수 있음영향 범위가 최소화 되도록 설계하기9.6 null 문제null 은 애초에 초기화하지 않은 메모리 영역에서 값을 읽으면 문제가 되기 때문에 이를 피하기 위해 발명된 것따라서 null 자체는 잘못된 처리를 나타냄“무언가를 갖고 있지 않은 상태”, “무언가 설정되지 않은 상태” 는 그 자체로 의미가 있는 상태이므로 null 로 ..

결합도란? : 모듈 사이의 의존도를 나타내는 지표강한 결합은 사용하기도, 수정하기도 힘들다8.1 결합도와 책무단일 책임의 원칙을 기억하면서 구현 → 클래스가 담당하는 책임은 하나로 제한하자DRY 원칙(Don’t repeat yourself)반복을 피해라 단, 비슷한 로직이라도 개념이 다르면 중복을 허용해야 한다.개념적으로 다른 것까지 무리하게 중복을 제거하면 강한 결합 상태가 된다8.2 다양한 강한 결합 사례와 대처 방법상속과 관련된 강한 결합상속은 반드시 단일 책임 원칙을 염두해 두고 구현해야함, 그리고 값 객체와 컴포지션 등 다른 설계를 할 수 없는지 반드시 선검토 해보자인스턴스 변수별로 클래스 분할이 가능한 로직양향 스케치 (의존 관계 그림) 활용하여 분리해보기특별한 이유 없이 public 사용하지..

배열과 List 같은 컬렉션을 따라다니는 단점 소개 및 퇴치 방법7.1 이미 존재하는 기능을 다시 구현하지 말기컬렉션에서 기본으로 제공하는 메서드 활용하기바퀴의 재발명 하지 말기바퀴의 재발명 : 이미 널리 사용되는 기술과 해결법이 존재하는데도, 이를 전혀 모르거나 의도적으로 무시하여 비슷한 것을 새로 만드는 것서비스 개발전 미리 프레임 워크의 기능과 라이브러리를 살펴보기!7.2 반복 처리 내부의 조건 분기 중첩조기 break 로 중첩 제거7.3 응집도가 낮은 컬렉션 처리일급 컬렉션컬렉션 처리를 캡슐화하기외부로 전달할 때 컬렉션의 변경 막기

6.1 조건 분기가 중첩되어 낮아지는 가독성얼리 리턴으로 중첩 제거하여 가독성 높이기6.2 Switch 조건문 중복같은 형태의 switch 문을 여러번 사용하는것은 매우 좋지 않음switch 조건문 중복을 해소하려면 단일 책임 선택의 원칙을 생각해 봐야 함즉, 조건식이 같은 조건 분기를 여러 번 작성하지 말고 한 번에 작성하자 (클래스 내부에 조건문 생성)인터페이스로 switch 조건문 중복 해소 하기6.3 조건 분기 중복과 중첩인터페이스는 switch 조건문의 중복을 제거할 수 있을 뿐 아니라, 다중 중첩된 복잡한 분기를 제거하는 데 활용 할 수 있음정책 패턴으로 조건 집약하기정책 패턴 : 조건을 부품처럼 만들고, 부품으로 만든 조건을 조합해서 사용하는 패턴6.4 자료형 확인에 조건 분기 사용하지 않기..

응집도란 모듈 내부에 있는 데이터와 로직 사이의 관계가 얼마나 강한지 나타내는 지표응집도가 높은 구조는 변경하기 쉬우며 바람직한 구조5.1 Static 메소드 오용데이터와 관련 로직을 모은다static 메소드는 언제 사용하는게 좋을까?아마 companion object 로 봤을 때? 응집도의 영향을 받지 않는 경우 예를들어 로그 출력, 포맷 변환5.2 초기화 로직 분산생성자를 Private 로 구현생성 로직이 너무 많아질 경우 생성 전용 팩토리 클래스로 분리5.3 범용 처리 클래스(Common/Util)너무 많은 로직이 한 클래스에 모이는 문제범용 이란 이름 자체로 범용적으로 사용하고 싶은 로직은 Common 에 모아두면 되겠다 생각꼭 필요한 경우가 아니라면 범 용 처리 클래스를 만들지 않는것이 좋음횡단..