JAVA/클린코드
클린코드 9장 (클래스), 10장 (시스템), 11장(창발성), 12장(동시성)
클래스 내부에서 동작하는 변수나 유틸리티는 protected로 선언하여 테스트에 사용하기도 한다. 클래스에 기본 규칙은 작게 만드는 것. 많을수록 클래스에 대한 책임이 너무 커진다. SPR을 지키기 위해 클래스가 너무 많아지면 사용에 더 어렵다고 우려할 수 있으나 하나의 여러 책임을 가지고 있는 클래스를 사용하는 것 보다 더 직관적 이므로 사용하기 더 편하다. 클래스 내부에 인스턴스 변수가 많아 진다는건 결국 클래스 내부에 함수와 인스턴스 변수들 사이에 응집도가 높아진다는 뜻이다. 이럴 수록 클래스를 분리해야 한다는 걸 의미한다. 긴 함수를 쪼갠다 → 작은 함수 여러 개로 만든다. → 몇몇 변수와 몇몇 함수만 사용 되는 경우가 보이면 클래스로 쪼갠다. 특정 기능이 변경 될 때 마다 코드가 변경되어야 하는..
클린코드 7장(경계), 8장 (단위 테스트)
경계 Map과 같은 공개된 인터페이스를 사용할 때 2가지 문제가 있다 1. 전달되는 map에 clear와 같은 삭제 명령어가 있어서 전달해주는 쪽에서 알지 못하고 지워지는 이슈가 있을 수 있다. 2. 전달된 Map 형태가 generic 하게 전해 졌어도 받는 쪽에서 Map map 등으로 받아 버린다면 캐스팅을 해서 사용하는 등의 문제나 변경의 소지가 크다. 또한 Map의 사용 방식이 변경된다면 이를 해결하기 위해 모든 부분에서 수정되어야 하는 문제가 있다. 그래서 이를 해결하기 위해서 Map에 사용 되는 Value 값의 객체에서 Map을 품어서 쓰는 방식으로 캡슐화하여 사용하기도 한다. public classs Sensors { private Map = new HashMap(); public Sensor..
클린코드 5장(객체와 자료구조), 6장 (오류처리)
객체와 자료구조 객체에서 자료를 세세하게 공개하는 것 보다 추상화를 통해 표현하는 것이 더 좋다. 객체는 동작을 공개하고 자료를 숨긴다. 복잡한 시스템을 짜다보면 새로운 함수가 아니라 새로운 자료타입이 필요한 경우가 발생하는데 이 때는 클래스와 객체 지향 기법이 적합하다. 하지만 새로운 함수가 필요하다면 절차지향 코드와 자료구조 형태가 더 적합한 코드이다. 오류처리 오류를 일일히 처리하는 것보다 차라리 예외를 던저버리는게 더 깔끔하다. 확인된 예외를 처리하기 위해서 하위 메소드에서 throws를 하게되면 상위 메소드에서 이 예외에 대한 명시가 되어야 하기 때문에 하위의 예외 때문에 상위 메소드가 수정되어야 하는 불상사가 발생하기 때문에 수정에 닫혀 있어야 하다는 OCP규칙을 위반한 것이다. 예외에 의미있..
클린코드 3장 (함수), 4장 (주석)
함수 - 함수를 만드는 기본 규칙은 작게 만드는 것! - 함수 내부에 if 문 등의 1단이나 2단 그 이상의 중첩 구조가 발생되면 안된다. - 함수의 활동은 한가지 그 이상을 하지마라. - switch문에 다음과 같이 한가지 작업만 해야한다는 SRP 이론과 코드의 변경이 있으면 안된다는 OCP 규칙을 위반한다. 이를 해결하기 위해서는 다형성을 이용해서 해결해야 한다. // 문제 코드 public int calEmployeePay(Employee e) { switch (e.type) { case SALARIED: return calculateSalariedPay(); case HOURLY: return calculateHourlyPay(); case ..... } } // 변경 내용 public inter..
클린코드 1장(깨끗한 코드), 2장 (의미있는 이름)
깨끗한 코드 태도 나쁜 코드는 생산성을 떨어트리고 갈수록 생산성 0로 수렴하게 만든다. 일정에 쫓겨서 만든 나쁜 코드를 나중에 고치려는 습관은 버려라. 르블랑의 법칙 대로 나중은 결코 오지 않는다. 핑계될 것 없다 모두 개발자 탓이다. 시간이 없어서 만든 잘못된 코드는 결국 일정을 빠르게 앞당기는 것이 아니라 결국 그 잘못된 코드로 일정을 지연시킨다. 깨끗한 코드란? 논리가 간단해야 한다. 의존성이 줄어 유지보수가 쉬워야 한다. 성능이 최적화 되어 있어야 한다. 오류는 확힐 하게 처리해야 한다. 많은 일을 하지말고 한가지 잘하는 일을 잘하는 코드를 만들어라. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 중복이 없다. 코드를 최대한 줄인다. 지속적으로 나빠지는 코드를 개선한다. 결론 백날 좋은 코드..