객체지향

1. 객체지향

현실에 존재하는 사물들을 그대로 모델링하여 사물들의 행위와 속성을 정의

객체 중심으로 실제 사물이 동작하는 방식으로 설계

절차 지향보다 편리하게 설계 가능

 

• 사물 : 객체 (Object)
• 사물이 하는 행위: Method
• 변수(Variable): 해당 사물이 가지는 속성 

2. 객체의 3요소

- 상태 유지 (객체의 상태)

 객체는 상태 정보를 저장, 유지되어야한다. 이러한 속성은 변수로 정의 되어야한다. 속상값이 바뀌면 객체의 상태가 변경 될 수 있어야한다.

 

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

메소드에 의해 제공

외부로부터 직접 속성에 접근하여 변경하는 것이 아니라 객체가 제공하는 메소드로 기능이 제공되어야함

 

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

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

카드번호, 계좌번호와 같은 속성을 통해 각각 고유한 값을 줄수 있다.

DB에서 Unique Key 나 Primary key로도 작성 가능 

 

3. 물리 객체와 개념 객체

- 물리 객체: 실제로 사물이 존재하며 이를 클래스로 정의한 객체

  ex) 자동차 렌탈 시스템: 자동차, 고객, 직원, 사업장, 정비소 ...

 

- 개념 객체: Web system에서 Service에 해당, businees logic을 처리하는 부분 

  - bussiness logic에서는 여러 객체를 서로 상호작용 하도록 함

  - 객체가 제공하는 오퍼레이션 method를 통해 객체의 속성 변경

  - ex) 사용자 관리시스템 : 사용자 객체의 마지막 접속일자를 이용하여 계정만료, 비밀번호 초기화 등등 

4. 객체지향의 4대 특성

  (1) 캡슐화: 객체의 속성을보호하기 위해 사용

 

• Method 설계

자신이 가지고 있는 속성에 대해서는 해당 상태를 변경하는 기능 제공

실물 객체가가진 기능을 모두 제공해야 한다.(ex. 자동차 렌탈, 반납, 주행거리 계산 등)

각각의 Method는 서로 관련이 존재해야 한다.

객체 안의 Method는 객체 안의 속성을 처리해야 하며, 다른 객체를 전달받아 해당 다른 객체에 정의된 속성을 직접 처리하면 안된다.(단, Method에 실행에 필요한 값들은 객체의 형태가 아닌 매개변수의 형태로 전달되어져야 한다.)

 

• 캡슐화 장점

 

- 추상화 제공

 Method 단순 호출만으로 해당 기능을 실행할 수 있음 -> 객체 단위로 프로그램 설계 가능 

 

- 재사용성 향상

한 객체에 관련된 속성과 Method는 모두 캡슐화의 형태를 제공함으로써 객체의 모듈성과 응집도가 높아져 재사용이 높아짐

 

- 유지보수의 효율성 향상 

추상화 제공 & 재사용성 향상을 통해 유지보수의 효율성 향상

 

- 무결성

캡슐화 코딩은 주로 변수를 private로 선언, Method를 publilc으로 선언 -> 객체의 무결성을 위함 

Getter/Setter을 제외하고 public method는 입력된 매개변수를 Validation한 후 실행하는 것을 기본으로 함

Validation을 통해 객체의 값을 바꾸거나 값에 대한 유효성을 가질 수 있다. 

 

• 캡슐화 메소드: Method 속성은 여러 속성에 해당될 수 있다.

- Getter/Setter Method

외부에서 내부 속성(Variable)에 직접 접근 하는 것이 아닌 Getter/Setter Method를 통해서 접근하도록 적용

 

- CRUD Method

데이터 처리를 위한 기본적인 CRUD Method를 제공

 

- Busineess Logic Method

비즈니스 로직 처리를 위한 Method를 제공

 

- 객체의 생명 주기 처리 Method

destory(), disconnect(), quit() 등 소멸에 대한 method

 

- 객체의 영구성 정리 

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

 

 

 (2) 상속: 객체지향에서의 상속은, 속성의 상속이 아닌, 하위로 내려갈 수록 구체화 되는 것

 

• 상속의 효과
  • 프로그램 구조에 대한 이해도가 향상된다(최상위 클래스의 구조를 보고 하위 클래스의 동작 이해가능)
  • 재사용성 향상 (해당 클래스에 필요한 속성 및 메소드를 모두 정의하지않고 상속을 이용하여 사용가능)
  • 확장성 향상 (일관된 형태로 클래스 객체 추가가 가능해 간단하게 프로그램 확장가능)
  • 유지보수성 향상 (각 개체마다 자신의 메소드를 정의하고 있다면 코드 수정에서 많은 작업이 필요하지만 상속을 이용한 경우에는 일관된 형태로 작성이 가능하다)

 (3) 다형성 : 하나의 개체가 여러 개의 형태로 변화하는 것, 다형성을 하기 위해서는 오버라이딩을 통해서 가능

 

 (4) 추상화 : 공통적인 부분 또는 특정 특성을 분리해여 재조합하는 부분  

• 객체 지향에서의 추상화는 모델링
• 다형성, 상속 모두 추상화에 속함 

 

5. 객체지향 설계 5원칙 SOLID

좋은 소프트웨어 설계를 위해서는 결합도를  낮추고 응집도를 높여야한다.

 

- 결합도(coupling)

모듈(클래스)간의 상호 의존 정도를 나타내는 지표 

결합도가 낮으면 모듈간의 상호 의존성이 줄어들어서 객체의 재사용과 유지보수 유리

 

- 응집도(cohension)

하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져, 재사용 및 유지보수가 용이 

 

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

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

 

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

 

자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야함

상위 클래스 또는 인터페이스를 중간데 둠으로써 자신의 변화에 대해서는 폐쇄적이지만, 인터페이스는 외부의 변화에 대해서 확장을 개방해 줄 수 있음

 

3.  LSP(Liskov Subtitution Principle) 리스코프 치환 원칙

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

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

클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.

프로젝트 요구 사항과 설계에 따라서 SRP(단일책임원칙)/ISP(인터페이스분리원칙)을 선택

 

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

: 자신보다 변하기 쉬운 것에 의존 X

6. POJO JAVA

POJO(Plain Old Java Object) 순수한 자바 오브젝트

 

1. 특정 규약에 종속 되지 않는다. 

특정 라이브러리나 모듈에서 정의된 클래스를 상속 받아서 구현하지 않아도 됨 

POJO가 되기 위해서는 외부의 의존성을 두지 않고 순수한 자바로 구성이 가능해야한다.

 

2. 특정 환경에 종속 되지 않는다.

특정 비즈니스 로직을 처리하는 부분에 외부 종속적인 http request, session 등 POJO를 위배한 것으로 간주 

 

3. Spring, Hibernate

두 프레임워크는 객체지향적인 설계, POJO 지향

 

(참고: fastcampus 한 번에 끝내는 Java/Spring 웹 개발 마스터)