1장 오브젝트와 의존관계(1) - 스프링

1장 오브젝트와 의존관계

 

1. 스프링의 핵심

-. 자바 기반 -> 자바는 객제지향 프로그래밍이 가능한 언어

-. 객체지향 프로그래밍이 제공하는 폭넓은 혜택을 누릴 수 있도록 기본으로 돌아가자는 것

-. 오브젝트의 효과적인 설계, 구현, 사용, 개선에 명쾌한 기준을 마련

 

1.1. 초난감 DAO

-. DAO (Data Access Object)는 DBㄹ르 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 Object

-. 자바빈(JavaBean) 은 원래 비주얼 툴에서 조작이 가능한 컴포넌트를 말하였으나, 사용성이 적어 그 의미가 사라짐

    디폴트 생성자, 프로퍼티를 가리키는 Object 의 의미를 가짐. 간단히 빈 이라고 부르기도 함

    디폴트 생성자 : 자바빈은 파라미터가 없는 디폴트 생성자를 갖고 있어야 한다. 툴이나 프래임워크에서 리플랙션을 이용해 오브젝트를 생성하기 때문에 필요하다.

    프로퍼티 : 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다. 프로퍼티는 set으로 시작하는 수정자 메소드(setter)와 get으로 시작하는 접근자 메소드(getter)를

이용해 수정 또는 조회할 수 있다.

 

-. JDBC를 이용하는 작업의 일반적 순서

1. DB 연결을 위한 Connnection을 가져온다.

2. SQL을 담은 Statement(또는 PreparedStatement)를 만든다.

3. 만들어진 Statement 를 실행한다.

4. 조회의 경우 SQL쿼리의 실행 결과를 ResultSet으로 받아서 정보를 저장할 오브젝트에 옮겨준다.

5. 작접 중에 생성된 Connnection, Statement, ResultSet 같은 리소스는 작업을 마친 후 반드시 닫아준다.

 

1.2. 메소드 분리

-. 개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 바로 미래의 변화를 어떻게 대비할 것이다.

-. 가장 좋은 대책은 변화의 폭을 최소한으로 줄여주는 것이다. (분리와 확장)

-.  분리

1. 중복 코드의 메소드 추출

2. 변경사항에 대한 검증: 리팩토링과 테스트 

리펙토링 리펙토링은 기존의 코드를 외부의 동작방식에는 변화 없이 내부 구조를 변경해서 재구성하는 작업 또는 기술을 말한다. 리펙토링을 하면 코드 내부의 설계가 개선되어 코드를 이해하기가 더 편해지고, 변화에 효율적으로 대응할 수 있다. 결국 생산성은 올라가고, 코드의 품질은 높아지며, 유지보수하기 용이해지고, 견고하면서도 유연한 제품을 개발 할 수 있다. 리펙토링이 절실히 필요한 코드의 특징을 나쁜 냄새라고 부르기도 한다. 대표적으로, 중복된 코드는 매우 흔하게 발견되는 나쁜 냄새다. 이런 코드는 적절한 리펙토링방법을 사용해 나쁜 냄새를 제거 해줘야 한다. 추천 - 리팩토링(마틴파울러, 캔트 백 공저)   c.f) 메소드 추출 - 공통의 기능을 담당하는 메소드로 중복된 코드를 뽑아내는 리펙토링

 

-. 확장

1. 상속을 통한 확장

-. 메소드의 추상화를 통하여 확장

템플릿 메소드패턴  슈퍼클래스에 기본적인 로직의 흐름(커넥션 가져오기 . SQL 생성. 실행， 반환)을 만들고，그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 protected 메소드 등으로만든 뒤 서브클래스에서 이런 메소드를 펼요에 맞게 구현해서 사용하도록 하는 방법   참고) 상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법이다. 변하지 않는 기능은 슈퍼클래스에 만들어두고 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 한다. 슈퍼클래스에서는 미리 추상메소드 또는 오버라이드 가능한 메소드를 정의해두고 이를 활용해 코드의 기본 알고리즘을 담고 있는 템플릿 메소드를 만든다. 슈퍼클래스에서 디폴트 기능을 정의해두거나 비워뒀다가 서브클래스에서 선택적으로 오버라이드 할 수 있도록 만들어둔 메소드를 훅(hook) 메소드라고 한다. 서브클래스에서는 추상메소드를 구현하거나, 훅 메소드를 오버라이드하는 방법을 이용해 기능의 일부를 확장한다.   public abstract class Super{     public void templateMethod(){         //기본 알고리즘 코드         hookMethod();         abstractMethod();         .......         //기본 알고리즘 골격을 담은 메소드를 템플릿 메소드라 부른다.         //템플릿 메소드는 서브클래스에서 오버라이드하거나 구현할 메소드를 사용한다.     }     protected void hookMethod(){} //선택적으로 오버라이드 가능한 훅 메소드     public abstract void abstractMethod(); //서브클래스에서 반드시 구현해야 하는 추상메소드 }   public class Sub1 extends Super{     protected void hookMethod(){         .........     }     public void abstractMethod(){         .........     } }    팩토리 메소드 패턴(factory method pattern)  서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것 참고) 팩토리 메소드 패턴도 템플릿 메소드 패턴과 마찬가지로 상속을 통해 기능을 확장하게 하는 패턴이다. 그래서 구조도 비슷하다. 슈퍼클래스 코드에서는 버스클래스에서 구현할 메소드를 호출해서 필요한 타입의 오브젝트를 가져와 사용한다. 이 메소드는 주로 인터페이스 타입으로 오브젝트를 리턴하므로 서브클래스에서 정확히 어떤 클래스의 오브젝트를 만들어 리턴할지는 슈퍼클래스에서는 알지 못한다. 사실 관심도 없다. 서브클래스는 다양한 방법으로 오브젝트를 생성하는 메소드를 재정의할 수 있다. 이렇게 서브클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메소드를 팩토리 메소드라고 하고, 이 방식을 통해 오브젝트 생성 방법을 나머지 로직, 즉 슈퍼클래스의 기본코드에서 독립시키는 방법을 팩토리 메소드 패턴이라고 한다.

 

디자인패턴  디자인 패턴은 소프트웨어 설계 시 특정 상황에서 자주 만나는 문제를 해결하기 위해 시용할 수 있는 재사용 가능한 솔루션을 말한다. 모든 패턴에는 간결한 이름이 있어서 잘 알려진 패턴을 적용하고자 할 때 간단히 패턴 이름을 언급하는 것만으로도 설계의 의도와 해결책을 함께 설명할 수 있다는 장점이 있다. 디자인 패턴은 주로 객체지향 설계에 관한 것이고， 대부분 객체지항적 설계 원칙을 이용해 문제를 해결한다. 패턴의 설계 구조률 보면 대부분 비슷한데. 그 이유는 객체지향적인 설계로부터 문제를 해결하기 위해 적용할 수 있는 확장성 추구 방법이 대부분 두 가지 구조로 정리되기 때문이다.  하나는 클래스 상속이고 다른 하나는 오브젝트 합성이다. 따라서 패턴의 결과로 나온 코드나 설계 구조만 보면 대부분 비슷해 보인다. 패턴에서 가장 중요한 것은 각 패턴의 핵심이 담긴 목적 또는 의도다. 패턴을 적용할 상황. 해결해야 할 문제，솔루션의 구조와 각 요소의 역할과 함께 핵심 의도가 무엇인지률 기억해둬야 한다.

 

-. 상속의 한계

1. 다중상속불가

 

2. 원칙과 패턴

2.1. 개방 폐쇄 원칙(Open-Closed Principal)

-. 깔끔한 설계를 위해 적용 가능한 객체지향 설계 원칙 중 하나

-. "클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다" 라고 정의할 수 있음

 

5가지 객체지향 설계 원칙 - SOLID -. SRP(The Single Responsibility Principal) : 단일 책임 원칙 -. OCP(The Open Closed Principal) : 개방 폐쇄 원칙 -. LSP(The Liskov Subsitution Principal) : 리스코프 치환 원칙 -. ISP(The Inteface Segregation Principal) : 인터페이스 분리 원칙 -. DIP(The Dependency Inversion Principal) : 의존관계 역전 원칙   로버트 마틴이 정리한 객체지향 설계 원칙인 SOUD어| 대한 소개는 관련 웹사이트 (http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod)

 

2.2. 높은 응집도와 낮은 결합도

2.2.1 높은 응집도

  -. 응집도가 높다는 것은 변화가 일어날 때 해당 모듈에서 변하는 부분이 크다는 것을 의미

  -. 응집도가 높다는 건 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어있다는 뜻

  -. 높은 응집도는 클래스 레벨뿐 아니라, 패키지, 컴포넌트, 모듈에 이르기까지 그 대상이 크기가 달라도 동일한 원리로 적용될 수 있다.

2.2.2 낮은 결합도

  -. 낮은 결합도는 높은 응집도보다 더 민감한 원칙이다.

  -. 관계를 유지하는데 최소한의 방법만 간접적인 형태로 제공.

  -. 서로 독립적이고 알 필요도 없게 만들어 주는 것

  -. 결합도가 낮아지면 변화에 대응하는 속도가 높아지고, 구성이 깔끔해지고 확장하기에도 매우 편리

  -. 결합도 란 "하나의 오브젝트가 변경이 일어날 때에 관계를 맺고 있는 다른 오브젝트에게 변화를 요구하는 정도" 라고 설명할 수 있다.

  -. 낮은 결합도 란 하나의 변경이 발생할 때 마치 파문이 이는 것처럼 여타 모듈과 객체로 변경에 대한 요구가 전파되지 않은 상태를 말한다.

  -. 결합도가 높아지면 변경에 따르는 작업량이 많아지고, 변경으로 인해 버그가 발생할 가능성이 높아짐

 

3. 전략패턴

-. 전략패턴은 디자인 패턴의 꽃이라고 불릴 만큼 다양하게 자주 사용되는 패턴이다.

-. 개방 폐쇄 원칙의 실현에도 가장 잘 들어맞는 패턴

-. 전략패턴은 자신의 기능 맥락(Context)에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 ㅍㄹ요에 따라 바꿔서 사용할 수 있게 한느 디자인 패턴이다.