1장 오브젝트와 의존관계 (1)

다음의 내용은 아래의 내용을 읽은 후 책에서 언급되는 구문을 기반으로 생각 정리한 글 입니다.

 

1.1 초난감 DAO
1.1.1 User
1.1.2 UserDao
1.1.3 main()을 이용한 DAO 테스트 코드
1.2 DAO의 분리
1.2.1 관심사의 분리
1.2.2 커넥션 만들기의 추출
UserDao의 관심사항
중복 코드의 메소드 추출
변경사항에 대한 검증: 리팩토링과 테스트
1.2.3 DB 커넥션 만들기의 독립, 상속을 통한 확장

 

 

 

0. 들어가기 앞서...

1장을 들어가기전에 들어가며를 읽었다.

읽고 난 소감과 근래 개발하면서 느낀점은 스프링부트는 스프링에서 요구하는 설정들에 대해 디폴트를 지원하고

빠르게 접근하기 위해 설정 과정을 간편화 시킨 것이고  스프링은 순수 자바를 잘 활용 할 수 있도록 추상화 한 프레임워크란 것이다. 항간에 누구는 스프링부트는 스프링을 추상화 한것이라고들 표현하는데 우리 GPT 형님은 다소 범주가 다른 설명이라고 하였다. 스프링을 잘 이해한다면 자바도 덩달아 잘 이해하지 않을까? 싶다.

 

1.스프링은 자바를 기반으로 한 프레임워크다. 스프링이 가장 관심을 많이 두는 대상은 객체(object) 이다.

스프링이 관심을 갖는 대상인 객체의 설계와 구현, 동작원리에 대해 더 집중하기를 바란다. 그러다보면 자연스럽게 스프링이 무엇인지 이해하게 될 것이다. 자바는 객체지향 프로그래밍 언어이고, 스프링은 객체지향 기술과 설계, 구현에 관한 실용적인 전력과 검증된 베스트 프랙티스를 자연스럽고 손쉽게 적용 할 수 있도록 프레임워크로 제공한다.

 

2. 자바 빈은 본래 비주얼 툴에서 사용하는 컴포넌트를 뜻하는데, 주력 기반이 WEB EE 바뀌면서 의미가 퇴색되었다.

근래엔 간단히 '빈(Bean)' 이라고도 부르며, 다음 두가지의 관례를 충족하는 객체를 부르는 용어로 의미가 전달된다.

ㆍ파라미터가 없는 기본 생성자를 지닌 객체. 리플랙션을 이용해 오브젝트를 생성하므로 생성자가 필요하다.

ㆍ프로퍼티 (getter and setter) 접근자를 가져 수정 또는 조회가 가능한 객체.

 

3. 단순한 플롯으로 기능이 잘 동작한다고해서 좋은 코드는 아니다.

개발자는 객체를 설계할 때 가장 염두해 둬야 할 사항은 '미래를 어떻게 대비할 것인가' 이다.

여기서 말하는 '사항' 은, 분리와 확장을 고려한 설계를 말하는 것이다.

객체지향 설계와 프로그래밍이 절차지향 프로그래밍 패러다임보다 손이 더 많이 가는 이유는 이 유연한 대처를 할 수 있기 때문이다. 코드를 분리와 확장을 한다는 것은 수행하고자 하는 클래스가 지닌 관심사(객체의 목적)을 같은 것 끼리 모으고, 다른 것 끼리는 쪼개는 과정을 일컫는다. 이를 프로그래밍 기초 개념에선 관심사의 분리(separation of concerns)라 한다.

 

4. 예제의 코드에선 db에서 user에게 데이터를 가져오려면 getConnection을 가져오는 만큼 n번 호출하여야 하고, 연결(connection)도 동일하게 n번째 호출하게 된다. 이를 분리하지않고 그냥 쓴다면 2천번을 호출했을때, connection도 2천번 호출되는 상황이 발생하며, db 로그인 정보가 바뀌었을 경우 로그인 정보도 직접 2천번을 다 수정 해야한다.

중복 된 코드를 외부 메서드로 분리하여 연결은 연결 담당, 데이터 조회는 조회담당하도록 하여 각자 주요 역할에 충실하도록 하게 한다.

 

5. 이러한 일련의 과정을 리팩토링(Refactoring) 이라 하며, 기존 코드를 외부 동작으론 변화없이 내부 구조를 변경하여 재구성하는 작업/기술을 뜻한다. 옳게 된 리팩토링은 코드 내부 설계가 개선되어 이해가 편해지고, 변화에 대응하기 용이해지므로 생산성, 코드품질, 유지보수 용이등 온갖 좋은 시너지를 유도한다.

흔히 리팩토링이 필요한 질 낮은 코드가 나타내는 특징을 나쁜 냄새 (bad small) 이라 일컫으며 대표적인 예시로는 위의 예제와 같이 중복 된 코드이다. 리팩토링은 개발자가 직관적으로 할 수도 있지만, 규모가 커질수록 학습과 훈련이 필요하다.

 

6. 디자인패턴은 소프트웨어 설계 중 자주 만나는 문제(pattern)를 해결하기 위해 사용 가능한 재사용 솔루션들을 일컫는다. 모든 패턴은 이름이 있어 잘 알려진 패턴을 적용하고자 한다면 간단히 이름만 언급하여도 설계 의도와 해결책을 같이 설명 할 수 있다는 장점이 있다. 패턴 설계 구조는 대부분 비슷한데 이는 객체지향 설계에서 문제 해결을 위한 해결 및 확장성 추구 방법이 대부분 클래스 상속, 오브젝트 합성 두가지이기 때문이다. 패턴에서 가장 중요한 것은 패턴이 가지고 있는 목적과 의도이다.

 

7. 템플릿 메서드 패턴은 상속을 통해 슈퍼 클래스의 기능을 확장 할 때 사용되는 가장 대표적인 방법이다.

슈퍼클래스에 변하지 않거나 공통적으로 사용하는 기능을 만들고 자주 변경되거나 확장 되는 기능을 서브(상속받는) 클래스에서 구현한다. 미리 추상 메서드나 오버라이드를 허용하는 메서드를 정의해두고, 서브 클래스에서 선택적으로 구현 할 수 있도록 하는 메서드를 훅(hock) 메서드라고 한다. 우리가 대학 커리큘럼에서 객체지향의 상속을 배울 때 쓰이는 예제로 이 내용이 주요 예시로 나올정도로 객체의 상속이란 개념과 가장 일치하는 디자인패턴이라고 볼 수 있다.

 

8. 팩토리 메서드 패턴은 템플릿 메서드 패턴과 마찬가지로 상속을 통해 기능을 확장하는 패턴이며, 템플릿 메서드와 구조도 비슷하다. (내용 추가 바람.) 이 패턴은 객체의 생성을 서브 클래스에게 책임을 맡겨 객체 생성의 변형을 가능하게 하는 패턴이다. 슈퍼클래스는 서브클래스가 어떻게 객체를 만드는지 모르지만 서브클래스에게 받은 객체를 기반으로 로직을 구현한다. 템플릿 메서드 패턴과의 가장 큰 차이점은 객체 생성의 주권이 누구에게 주어지는가? 라고 볼 수 있다.