10장 클래스
클래스 체계
클래스 내부 선언 순서는 표준 자바 관례에 따라 정의가 되어있다.
그 순서는 다음과 같다.
- 정적 공개 상수 (static public)
- 정적 비공개 변수 (static private)
- 비공개 인스턴스 변수
- 공개 변수(거의 존재하지 않는 경우)
- 공개 함수
- 비공개 함수(자신을 호출하는 공개 함수 직후에)
때로는 변수나 함수를 protected로 선언하여 테스트 코드에서 접근을 허용하기도 한다.
같은 패키지 안에서 함수 등을 호출하여 테스트 해야한다면, protected로 쓰되 비공개 상태를 유지할
방법을 강구한다. 캡슐화는 항상 지키도록 노력할 것.
클래스는 작아야 한다
클래스의 이름을 지을때는 해당 클래스의 역할을 기술해야한다.
한 클래스의 역할이 너무 많아서는 안된다.
단일 책임 원칙 (SRP) 란?
SRP는 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다는 원칙이다.
한 클래스 여러가지 책임을 떠안아서, 여러 이유로 변경이 되어야 한다면 이는 SRP를 지키지 못하는 것이다.
훗날 변경이 필요할 때, 직접 영향을 미치는 컴포넌트만 이해해도 괜찮도록 체계적인 정리를 하자.
큰 클래스 몇개 보다 작은 클래스 여럿으로 이루어진 시스템이 더 바람직하다.
응집도란?
메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 높다고 표현한다.
그리고 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아질 경우, 새로운 클래스로 쪼개는 것이 바람직하다.
변경하기 쉬운 클래스
OCP(Open-Closed Principle) 이란?
OCP란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야한다는 원칙이다.
클래스를 만들때는 파생 클래스를 생성하기 쉽도록 제작해야한다.
DIP(Dependency Inversion Principle)이란?
클래스는 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙.
주식 가격을 반환하는 클래스는, 주가를 얻어오는 출처나 얻어오는 방식 등을 숨긴 채
주식 가격을 반환한다는 추상적인 개념을 표현한다.
11장 시스템
시스템 제작과 시스템 사용을 분리하라
소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다.
AOP(Aspect-Oriented Programming) 란?
프로그램에서 트랜잭션, 보안, 로깅, 에러 핸들링 등 부가적인 기능들을 횡단 관심사라고 일컫는데,
이러한 것들은 여러 모듈 또는 객체들 사이에서 공통으로 적용된다.
AOP는 이러한 횡단관심사를 주요 비즈니스 로직과 분리하여 모듈화하고 개발하는 기술이다.
AOP의 주요 개념은 다음과 같다.
- 관점(Aspect): 횡단 관심사를 정의한 모듈을 말합니다. 주로 로깅, 보안, 트랜잭션 관리 등이 관점에 해당합니다.
- 조인 포인트(Join Point): 관점이 적용될 수 있는 위치를 말합니다. 주요 비즈니스 로직 내의 특정 메서드 호출, 필드 변경 등이 조인 포인트가 될 수 있습니다.
- 어드바이스(Advice): 관점이 적용될 때 실제로 수행되는 동작을 말합니다. 관점이 언제 적용되어야 하는지, 어떤 추가 동작을 하는지 등을 정의합니다.
- 포인트컷(Pointcut): 어떤 조인 포인트에 어떤 어드바이스를 적용할지를 선택하는 기준을 말합니다.
- 위빙(Weaving): 관점을 주요 비즈니스 로직에 적용하는 과정을 말합니다. 즉, AOP 프레임워크가 관점을 코드에 삽입하는 작업을 수행합니다.
AOP는 다양한 프레임워크에서 지원하는데, JAVA Spring에서도 이를 지원한다.
POJO란?
POJO의 특징은 다음과 같다.
- 상속을 받지 않거나 특정 인터페이스를 구현하지 않는다.
- 특정 프레임워크에 종속되지 않으며, 일반적인 자바 개발 기술만으로 작성된다.
- 특정 어노테이션을 요구하지 않는다.
- 복잡한 추상화나 라이브러리 의존성 없이도 독립적으로 동작할 수 있다.
POJO는 순수하게 도메인에 초점을 맞추기 때문에 프레임워크에 의존하지 않아 테스트가 개념적으로 쉽고 간단하다.
테스트 주도 시스템 아키텍처 구축
코드 수준에서 아키텍처 관심사를 분리해 개발할 수 있따면, 진정한 테스트 주도 아키텍처 구축 가능.
따라서 애플리케이션 도메인 논리를 POJO로 작성할 수 있도록 하자.
결론
깨끗하지 못한 아키텍처는 노메인 논리를 흐린다.
TDD의 장점을 살리려면 모든 추상화 단계에서 의도는 명확히 표현해야 하고, POJO를 작성하고
각 구현관심사를 분리해야 한다. 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용하자.
'📖BOOK > 📙Clean Code' 카테고리의 다른 글
| [클린 코드] - 12장 창발성, 13장 동시성 (0) | 2023.07.20 |
|---|
