반응형
TIL (Today I Learned)
2022.02.22
오늘 읽은 범위
3장. 함수
책에서 기억하고 싶은 내용을 써보세요.
- 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. (p.43)
- if문 /else 문 /while 문 등에 들어가는 블록은 한 줄이어야 한다는 의미. 대개 거기서 함수를 호출(p.44)
코드로 다시 한번 상기하자.
//모든 코드가 아닌 if문으로만 확인.
//올바르지 못한 버전
if(isTestPage){
WikiPage testPage=pageData.getWikiPage();
StringBuffer newPageContent = new StringBuffer();
//이렇게 코드가 if문에서 계속 이어진다.
}
//올바른 버전
if(isTestPage) includeSetupAndTeardownPages(pageData,isSuite);
- 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다. (p.44)
- 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. (p.45)
- 함수에서 이상적인 인수 개수는 0개다. 다음은 1개(단항)고, 다음은 2개(이항)다. (p.50)
- 오류 코드보다 예외를 사용하라! (p.57)
- 오류 코드 대신 예외를 사용하면 새 예외는 Exception 클래스에서 파생된다. 따라서 재컴파일/ 재배치 없이도 새 예외 클래스를 추가할 수 있다.
- 중복은 소프트웨어에서 모든 악의 근원이다. (p.60)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- Java 테스트 코드에서 많이 사용하는 assertEquals(expected, actual) 내용이 공감이 많이 갔다. 아직도 처음에 들어갈 인자가 예상 값인지, 비교할 실제 값인지 많이 헷갈린다. expected 다음에 equals가 오는 순서를 인위적으로 기억해야 한다. 그러나 예를 들어 assertEquals 보다 assertExpectedEqualsActual가 함수 이름이면 인자 순서를 인위적으로 기억할 필요도 없고 코드를 보는 입장에서 사용법이 더욱더 와닿을 것이라고 느꼈다.
- try/catch 문을 사용하면 그동안 매번 성공 로직을 try문에 때려 넣었다. 이번 학습을 계기로 try/catch 블록을 별도 함수로 뽑아내야겠다고 다짐했다.
- 앞으로는 Exception을 상속받아 본인이 재정의한 예외 클래스를 바탕으로 예외를 처리하려고 노력하겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- Switch문을 작게 만드는 것은 어렵다. 또한 '한 가지' 작업만 수행하는 Switch문을 만드는 것은 더욱 어렵다. Switch문을 완벽하게 피할 방법은 없지만, 각 Switch 문을 저 차원 클래스에 숨기고 절대로 반복하지 않는 방법이 있다. 인터페이스를 사용해 다형성을 활용하는 것이다. Switch 문을 추상 팩토리에 숨겨서 보여주지 않는다. 이런 방식을 통해 우리는 Switch문을 다시는 작성할 필요가 없다. 예시 코드는 아래와 같다.
public interface EmployeeFactory{
public Employee makeEmployee(EmployeeRecore r)throws InvalidEmployeeType;
}
public class EmployeeFactoryImpl implements EmployeeFactory{
public Employee(EmployeeRecord r)throws InvalidEmployeeType{
switch (r.type){
case COMMISSIONED:
return new CommissiondEmployee(r);
case HOURLY:
return new HourlyEmployee(r);
case SALARIED:
return new SalariedEmployee(r);
default:
throw new InvalidEmployeeType(r.type);
}
}
}
- 그러면 추상 팩토리란 무엇인가? GOF 디자인 패턴에서 등장하는 생성 패턴이다.
- 구체적인 클래스에 의존하지 않고, 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현한다. 즉 구현 클래스가 아닌 인터페이스에 의존하면 된다. 인터페이스에 의존해서 구현이 되므로 앞에서 설명한 서로 연관, 의존하는 객체들의 그룹을 생성할 수 있다.
- 연관된 서브 클래스를 묶어 한 번에 교체 가능하다.
반응형
댓글