switch문을 저차원 클래스에 숨기고 절대 반복하지 않는 방법: 다형성(polymorphism)
ex. 직원 유형에 따라 switch문으로 다른 함수를 호출해야하는 경우
-> switch문을 추상 팩토리 클래스에 숨긴다
-> 팩토리는 switch문을 이용해 적절한 Employee 파생 클래스의 인스턴스를 생성한다
-> Employee 인터페이스를 거쳐 함수를 호출한다
-> 다형성으로 인해 실제 파생 클래스의 함수가 실행된다
서술적인 이름을 사용하라!
길고 서술적인 이름이 짧고 어려운 이름보다 낫다
길고 서술적인 이름이 길고 서술적인 주석보다 낫다
함수 인수
함수에서 인수 개수는 적을수록 좋다
0개 사용하는 것이 최선이다
4개 이상은 사용하면 안된다!
일반적으로 우리는 인수를 함수 입력으로 해석
-> 출력 인수 사용 X
많이 쓰는 단항 함수
(1) 인수에 질문을 던지는 경우
(2) 인수를 변환해 결과를 반환하는 경우
(3) 이벤트 함수
입력 인수만 있고 출력 인수가 없다
입력 인수로 시스템 상태를 바꾼다
위 경우가 아니라면, 단항 함수는 가급적 피한다
플래그 인수: 함수로 부울 값을 넘기는 것은 추하다!
-> true일 때 호출될 함수, false일 때 호출될 함수로 나누기
이항 함수/삼항 함수:
인수의 순서를 인위적으로 기억해야함 -> 실수할 위험
가능하면 단항 함수로 바꾸어야
인수 객체
인수 2~3개가 필요하다면 -> 독자적인 클래스 변수로 선언하기
인수 목록
인수 개수가 가변적인 함수 -> List형 인수 하나로 취급
좋은 함수 이름
함수와 인수가 동사-명사 쌍을 이루기
ex. writeField(name)
함수 이름에 인수 이름 넣기 -> 인수 순서 기억할 필요 X
ex. assertExpectedEqualsActual(expected, actual)
부수 효과를 일으키지 마라!
시간적인 결합(temporal coupling) 초래
-> 특정 상황에서만 호출 가능
순서 종속성(order dependency) 초래
명령과 조회를 분리하라!
객체 상태를 변경하거나, 객체 정보를 반환하거나 둘 중 하나만 해야한다
오류 코드보다 예외를 사용하라!
명령 함수에서 오류 코드를 반환하는 형식 -> 명령/조회 분리 규칙 위반
Error.java 의존성 자석
오류 코드를 반환한다는 것 = 어디선가 오류 코드를 정의한다는 뜻(ex. enum class)
다른 클래스에서 오류 코드를 import해서 사용
-> 오류 코드 클래스가 변한다면, 오류 코드를 사용하는 클래서 전부 변경해야
오류 코드 대신 예외(try-catch) 사용하기
-> try-catch 블록을 별도 함수로 뽑아내기
-> try 블록에서 수행될 정상 동작 함수, catch 블록에서 수행될 오류 처리 동작 함수로 분리
반복하지 마라!
구조적 프로그래밍
애츠허르 데이크스트라(Edsger Dijkstra)의 구조적 프로그래밍 원칙:
모든 함수와 모든 함수 내 모든 블록은 entry와 sxit이 하나만 존재해야