Clean Code

1. 시스템
박기덕

2. 목차
1. 제작과 사용의 분리
2. 확장
3. 자바 프록시
4. 순수 Java AOP 프레임워크
5. 결론

4. 1. 제작과 사용의 분리
● 소프트웨어 시스템은 '시작'과 '실행'으로 분리
○ 시작 : 응용 프로그램 객체를 제작하고 의존성을 서로 연결하는 단계
○ 실행 : 시작 단계 이후에 실제로 동작하는 단계
● 시작 단계는 모든 응용 프로그램이 풀어야 할 관심사이
며, 관심사 분리는 우리 분야에서 가장 오래되고 가장 중
요한 설계 기법
● 설정 논리는 일반 실행 논리와 분리해 모듈성을 높이고,
주요 의존성 해소 필요

5. 1. 제작과 사용의 분리
초기화 지연(Lazy Initialization) or 계산 지연(Lazy Evaluation) 기법
● 장점
○ 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하 제거
○ Null Return 제거
● 단점
○ getService() 메소드의 MyServiceImpl 과 생성자 인수에 의존
○ 테스트의 복잡성 증가

6. 1. 제작과 사용의 분리
● 생성과 관련된 코드는 모두 main이 담당
● main에서 객체를 생성해 application으로 전달하고 객체
의 사용은 application에서 진행(application은 객체가 생
성되는 과정은 알지 못한다.)

7. 1. 제작과 사용의 분리
● application에서 객체를 생성할 때는 Abstract Factory 패
턴을 사용
● LineItem을 생성하는 시점은 OrderProcessing이 결정하
지만 생성은 main이 담당

8. 1. 제작과 사용의 분리
● 의존성 주입(DI)은 제어 역전(IoC)기법을 의존성 관리에
적용한 메커니즘
● 클래스가 의존성을 제어하지 않고 수동적으로 DI 컨테이
너에서 제어
● DI 컨테이너는 요청이 들어올 때 마다 필요한 객체의 인
스턴스를 만든 후 생성자 인수나 설정 메소드를 사용해
의존성을 설정

9. 2. 확장
● 소프트웨어 시스템은 물리적 시스템과 다르다. 관심사를
적절히 분리해서 관리해야 소프트웨어 아키텍처는 점진
적으로 발전

10. 2. 확장
● 비즈니스 논리는 EJB2 컨테이너
에 강하게 결합된다.
● 클래스 생성 시 컨테이너에서 파
생되야 하고, 컨테이너가 요구하
는 생성주기 메소드도 제공해야
하기 때문
● 위와 같이 비즈니스 논리가 덩치
큰 컨테이너와 밀접하게 결합되
서 단위 테스트가 어렵고, EJB2
코드는 프레임워크 밖에서는 재
사용이 불가능 해진다.

11. 2. 확장
● EJB2 아키텍처는 일부 영역에서 관심사를 거의 완벽하
게 분리한다. 예를 들어, 원하는 트랜잭션, 보안, 일부 영
속적인 동작은 소스 코드가 아니라 배치 기술자에 정의
한다.
● EJB 아키첵처의 이러한 방식이 관점 지향 프로그래밍
(AOP)를 예견했다고 보인다.
● AOP에서 aspect라는 모듈 구성 개념은 "특정 관심사를
지원하려면 시스템에서 특정 지점들이 동작하는 방식을
일괄적으로 바꿔야 한다"라고 명시 한다.

12. 3. 자바 프록시
bank.getAccounts();
List<Account> act = new ArrayList<Account> ();
bank.setAccounts(act);

13. 3. 자바 프록시
● 자바 프록시는 개별 객체나 클래스에서 메소드 호출을
감싸는 경우 사용 (단순한 사용에 적합)
● JDK에서 제공하는 동적 프록시는 인터페이스만을 지원
하고 클래스 프록시를 사용하려면 CGLIB, ASM,
Javassist 등과 같은 바이트 코드 처리 라이브러리 필요
● BankProxyHandler는 자바 리플렉션 API를 사용해 제네
릭 메소드를 상응하는 BankImpl 메소드로 사상
● 코드 '양', '크기'는 프록지의 단점이며, 프록시를 사용하
면 클린 코드를 작성하기 어렵다.

14. 4. 순수 Java AOP 프레임워크
● 스프링은 비즈니스 논리를 POJO(Plain-Old Java Object)
로 구현
● 스프링 프레임워크는 사용자가 모르게 프록시나 바이트
코드 라이브러리를 사용해 앞에서 살펴본 횡단 관심사를
구현
● 즉, 요청에 따라 주요 객체를 생성하고 서로 연결하는 등
DI 컨테이너의 구체적인 동작을 제어

15. 4. 순수 Java AOP 프레임워크
● bank 객체는 DAO로 프록시 되고, DAO는 JDBC 드라이버로 프록시 된다.
● 클라이언트는 bank 객체에서 getAccounts()를 호출한다고 믿지만 실제로 bank POJO의 기
본 동작을 확장한 중첩 Decorator 객체 집합의 가장 외곽과 통신 ( 즉, bank객체에서
getAccounts()를 호출하면 실질적인 동작은 appDataSource에서 DB작업을 실행한다.)

16. 4. 순수 Java AOP 프레임워크
● 응용 프로그램에서 DI 컨테이너에게 시스템 내 최상위
객체를 요청하려면 아래와 같이 요청
XmlBeanFactory bf = new XmlBeanFactory(new ClassPathResource("app.xml", getClass()));
Bank bank = (Bank) bf.getBean("bank");
● 스프링에 관련한 자바 코드가 거의 필요 없으므로 응용
프로그램은 사실상 스프링과 독립적이므로 EJB2 시스템
이 지녔던 강한 결합성 문제가 해결
● XML을 사용하면 '정책'이 겉으로 보이지 않지만 자동으
로 생성되는 프록시나 관점 논리보다는 단순하며, 이러
한 장점이 EJB3에서 횡단 관심사를 선언적으로 지원하
는 스프링 모델을 따르도록 변경하게 만들었다.

17. 4. 순수 Java AOP 프레임워크
● EJB2에서 사용했던 프레임워크 의존
적인 부분이 사라진 것을 확인 할 수
있다.
● 일부 상세한 정보는 주석에 포함되어
그대로 남아있지만, 모든 정보가 주석
속에 있으므로 코드 자체는 깔끔하고
깨끗해 진다.
● 즉, 코드를 테스트하고, 개선하고, 보
수하기가 용이해졌다.
● 주석으로 들어있는 영속성 정보는 일
부든 전부든, 필요하다면 xml 배치 기
술자로 옮겨 사용해도 된다. 그러면
POJO가 되게 된다.

18. 5. 결론
● 의사 결정을 최적화 하라.
○ 관심사를 모듈로 분리한 POJO 시스템 사용
● 명백한 가치가 있을 때 표준을 현명하게 사용하라.
○ 표준을 사용하면 재사용이 쉽고, 캡슐화가 용이하고, 컴포넌트를 엮기
쉽지만, 시간이 너무 오래걸리고, 복잡도를 증가 시킬 가능성이 존재
● 시스템은 도메인 특화 언어가 필요하다.
○ DSL(Domain-Specifie Language)을 사용하면 고차원 정책에서 저차원
세부 사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표
현 가능
● 시스템은 깨끗 해야 한다. 즉, 이해하기 쉽고, 단순하며,
관점이 잘 분리되어야 한다.