객체지향 이론

1. 객체지향

객체지향의 개념은 1970년에 등장했으며 이전에는 C 언어처럼 실행하고자 하는 순서로 명령어를 처리하는 절차지향을 주로 사용해 왔다.
이후 프로그램의 복잡도가 높아지면서 이에 들어가는 유지보수, 개발기간 등의 다양한 부분에서 비 효율이 발생하면서
많은 개발자들이 효과적인 개발 방싱의 방법을 채택하게 되고 새로운 방식의 객체지향의 방법을 적용하게 된다

현실에 존재하는 사물을 있는 그대로 모델링하여, 이들의 행위와 속성을 정희하고, 절차적이 아닌 객체가 중심이 되어 실제 사물이 동작하는 방식으로
설계하였다.

1-1 객체 설계하기

• 객체의 3 요소
  • 상대 유지(객체의 상태)

    객체는 상대 정보를 저장하고, 유지되어야하며 이러한 속정은 변수로 정의 되어져야한다. 
    이러한 속성값이 바뀜으로 인하여, 객체의 상태가 변경될 수 있다.

  • 기능 제공(객체의 책임)

    객체는 기능을 재공하야한다. 이 부분은 Method의 제공으로 이루어진다.
    캡슐화와 연관이 있으며, 외부로 부터 직접 속성에 접근하여 변경하는 것이 아닌 객체가 제공하는 Method로 기능이 제공되어져야한다.

  • 고유 식별자 제공 (객체의 유일성)

    각각의 객체는 고유한 식별자를 가져야한다.

1-2 객체지향의 특성

A. 캡슐화

• 속성을 보호하기 위해 사용하며 Methd를 설계하여 적용할 수 있다.

  • 속성이 선언되었으나 상태를 변경하는 Method 가 없다면, 잘못 선언된 속성이다.
  • 실물 객체가 가진 기능을 모두 제공하야한다.
  • 각각의 Method는 서로 관련성이 있어야한다.
  • 객체 안의 Method는 객체 안의 속성을 처리해야 하며, 다른 객체를 전달받아 해당 다른 객체에 전의 된 속성을 직접 처리하면 안된다.

• Getter / Setter 메소드

  • 외부에서 내부 속성으로 직접 접근하는 것이 아닌 Getter / Setter 메소드를 통해서 접근하도록 적용

• CRUD 메소드
  • 데이터 처리를 위한 기본적인 CRUD 메소드 제공

• 객체의 생명 주기 처리 메소드
  • destroy(), disconnect(), quid() 등 소명에 대한 메소드

• 객체의 영구성 관리 메소드
  • 영구성(유효성) 속성에 대한 변경이 필요한 경우 외부에서는 접근이 불가능 하도록 private로 선언하며, 내부의 다른 메소드를 통해서 사용 되도록 한다.

• 장점
  • 객체지향의 패러다임 중 하나인 추상화를 제공한다.
  • 재사용성, 효율성 향상

B. 상속

• 객체지향에서의 상속은, 속성의 상속이 아닌, 하위로 내려갈 수록 구체화 되는 것이다.
  • 상속의 효과
    • 프로그램 구조에 대한 이해도 향상
    • 재사용성 향상
    • 확장성 향상
    • 유지보수성 향상

C. 다형성

• 다형성은 하나의 개체가 여러 개의 형태로 변화 하는것을 말하여, 이를 객체지향에서도 유사하게 사용한다.
• 다형성은 Overriding을 통해서 가능하다.

D. 추상화

• 객체지향에서의 추상화는 모델링이다.
• 구체적으로 공동적인 부분, 또는 특정 특성을 분리해서 재조합하는 부분이 추상화이다.
• 앞선 내용 다형성, 상속 모두 추상화에 속한다.

객체지향 설계 5원칙

좋은 SW는 결합도는 낮추고 응집도는 높여야한다.

결합도와 응집도

• 결합도 : 클래스간의 상호 의존 정도를 나타내는 지표로써 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어서 객체의 재사용 및 유지보수가 유리하다.
• 응집도 : 하나의 클래스 내부에 존재하는 구성 요소들의 기능적 관련성으로 응집도가 높은 클래스는 하나의 책임에 집중하고 독립성이 높아져, 재사용 및 유지보수가 용이하다.

1. SRP(Single Responsibility Principle) : 단일 책임의 원칙

• 어떠한 클래스를 변경해야하는 이유는 한가지 뿐 이어야한다.

2. OCP(Open Closed Priciple) : 개방 폐쇄 원칙

• 자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀야한다.
• 상위 클래스 또는 인터페이스를 중간에 둠으로써, 자신은 변화에 대해서는 폐쇄적이지마느 인터페이스는 외부의 변화에 대해서 확장을 개방해 줄 수 있다.
  이러한 부분은 JDBC와 Mybatis, Hibernate 등 JAVA에서는 Stream(Input, Output)에서 볼 수 있다.

3. LSP(Liskov Substitution principle) : 리스코프 치환 원칙

• 서브 타입은 언제나 자신의 기반(상위) 타입으로 교체 할 수 있어야 한다.

4. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙

• 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다.
• 프로젝트 요구 사항와 설계에 따라서 SRP / ISP 를 선택 한다.

5. DIP(Dependency Inversion Priciple) : 의존 역전 원칙

• 자신보다 변하기 쉬운 것에 의존하지 말아야 한다.

POJO(Plain Old Java Object)

순수한 자바 오브젝트를 뜻하며 EJB를 사용하던 사절에는 단순히 자바 오브젝트를 사용해서 개발하는 것이 아닌 EJB에 종속적인 부분으로 개발을 진행
때문에 모듈의 교체, 시스템 업그레이드시 종속성으로 인하여 불편함 발생

특징

1. 특정 규약에 종속 되지 않는다.
   특정 Library, Module에서 정의된 클래스를 상속 받아서 구현하지 않아도 된다.
   POJO가 되기 위해서는 외부의 의존성을 두지 않고, 순수한 JAVA로 구성이 가능해야한다.

2. 특정 환경에 종속되지 않는다.
   만일 특정 비즈니스 로직을 처리하는 부분에 외부 종속적인 요소가 포함될 경우 이를 위배한 것으로 판단하다.

   또한 많이 사용되고 있지만 @Annotation 기반으로 설정하는 부분도 엄연히는 POJO라고 볼 수 ㅇ없다.

POJO Framework

1. Spring, Hibernate
   하나의 서비스를 개발하기 위해, 시스템 및 서비스의 복잡성을 마주하게 되는데 해당 프레임 워크는 객체지향적인 설계의 특성을 지니고 있으며 POJO를 지향하고 있다.