터미널에서 GUI로 넘어오면서 점차 프로그래밍이 복잡해지기 시작
함수를 활용하다 새로운 시각으로 프로그래밍 시작!
객체지향
현실에 존재하는 사물을 있는 그대로 모델링하여,
이들의 행위와 속성을 정의,
절차적 X, 객체가 중심이 되어 실제 사물이 동작하는 방식으로 설계
이는
사물에 대해서 "객체"
해당 사물이 하는 행위 "메소드"
해당 사물이 가지는 속성 "변수"
장점
자바는 가비지 콜렉터로 자동으로 사용하지 않고 있는 메모리를 해제
JVM만 있으면 어떤 운영체제에서도 독립적으로 실행 가능하도록 설계 -> 여러 플랫폼에서 호환성을 제공하는 장점
객체의 3가지 요소
- 상태 유지(객체의 상태)
객체는 상태 정보 저장/유지되어야 하며
이러한 속성은 변수로 정의되어져야 함
속성값 바뀌면 객체 상태가 변경되어야 한다.
- 기능 제공(객체의 책임)
객체는 기능을 제공해야 한다.
캡슐화 -> 외부로부터 직접 속성에 접근하여 변경하는 것이 아니라,
객체가 제공하는 메소드로 기능이 제공되어져야 한다.
- 고유 식별자 제공(객체의 유일성)
각각의 객쳊는 고유 식별자를 가져야한다.
(DB에서 Unique Key, Primary Key)
물리 객체와 개념 객체
- 물리 객체
실제로 사물이 존재하며, 이를 클래스로 정의한 객체
(급여 관리 시스템 : 직원/월급 통장 등등..)
- 개념 객체
웹 시스템에서 service에 해당, 이는 business logic을 처리
여러 객체를 서로 상호작용하도록 하고, 객체가 제공하는 오퍼레이션(method)를 통해 객체 속성 변경
(사용자 관리 시스템 : 사용자 객체의 마지막 접속일자 확인 -> 계정 만료/비밀번호 초기화/재등록 처리 등)
객체지향에서의 대부분의 코딩 :
각 객체에 기능 정의
Service에서 객체의 메소드를 활용, 여러가지 조건 확인, 객체 속성 변경하는 작업이 주된 코딩이 됨.
그러므로 각 객체의 속성, 속성/상태 변경 메소드 잘 정의해야함
객체지향의 4대 특성
1. 캡슐화
객체의 속성을 보호하기 위해 사용
(컴퓨터 본체 안에 메인보드에 직접 연결이 아닌, 외부 케이스로 전원 버튼 통해 상태 속성 ON/OFF)
메소드 설계
-자신이 가진 속성에 대해 해당 상태 변경 기능 제공
-실물 객체가 가진 기능 모두 제공
-각각의 메소드가 서로 관련성 있어야 함
-객체 안의 메소드는 객체 안의 속성 처리해야한다. (다른 객체 전달받아 속성 직접 처리 X)
-메소드 실행에 필요한 값들은 매개변수 형태로 전달
장점
1. 추상화 제공 가능 -> 메소드가 어떻게 동작하는지 외부에서 이해 필요 X
단순 호출만으로 해당 기능 실행 가능 -> 이를 통해 객체 단위로 프로그램 설계 가능
2. 재 사용성 향상
객체의 속성/메소드는 모두 캡슐화로 제공 -> 객체의 모듈성&응집도 향상 -> 재사용성 높아짐
변수가 객체 안에 있기 때문에 전역 변수가 딱히 큰 필요성이 없다
결론 : 유지 보수 효율성 향상
3. 무결성(정확성/일관성 유지)
변수 -> private 선언
함수 -> public 선언
게터/세터 제외하고는 public method는 입력된 매개변수를 validation을 한 후 실행하는 것을 기본
-> 객체 값 바꾸기/유효성 가지기
2. 상속
객체지향에서의 상속은
하위로 내려갈수록 구체화된다!
상속의 효과
- 프로그램 구조에 대한 이해도 향상 : 최상위 클래스 구조 보고 하위 클래스 동작 이해 가능
- 재사용성 향상 : 클래스에 필요한 속성 및 메소드 모두 정의 안하고 상속받기
- 확장성 향상 : 일관된 형태의 클래스 객체 추가 -> 간단하게 확장 가능
- 유지 보수성 향상 : 각 객체마다 자신의 메소드 정의하고 있으면 코드 수정에서 많은 작업이 필요하지만 상속을 사용한 경우 일관된 형태로 작성 가능
3. 다형성
하나의 개체가 여러 형태로 변화하는 것 -> 오버라이딩 통해 가능
4. 추상화
객체지향에서의 추상화는 모델링
구체적으로, 공통적인 부분/특정 특성 분리해 재조합하는 것이 추상화
다형성/상속 모두 추상화에 속함
추상이란 구상에 반대되는 개념으로, 어떤 대상 혹은 세계로부터 하나의 상을 추려내어 표현하는 것
객체지향 설계 원칙
좋은 소프트웨어 설계 위해서는
결합도 ↘ 응집도 ↗
1. 결합도 : 모듈(클래스)간 상호 의존 정도 나타내는 지표
결합도가 낮으면 모듈 간 상호 의존성 줄어들어 객체 재사용 및 유지보수 유리
2. 응집도 : 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성
응집도 높은 모듈 -> 하나의 책임에 집중하고 독립성이 높아져 재사용 및 유지보수 용이
1. SRP(Single Responsibility Principle) : 단일 책임 원칙
FTP Client가 너무나도 많은 기능을 가지고 있기 때문에,
기능을 따로 분리해준다.
로컬 파일 로더가 응집도가 강한(책임감이 강한) 파일 리더를 갖다 쓴다.
다른 모듈들이 추가되더라도, 재사용 가능 유리!
코드를 예로 들어보자.
단일 책임을 주기 위해,
그리고 다형성을 주기 위해 오버라이딩을 한다.
2. OCP(Open Closed Principle) : 개방 폐쇄 원칙
자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다.
상위 클래스 또는 인터페이스를 중간에 둠으로써,
자신의 변화에는 폐쇄적
인터페이스는 외부의 변화에 대해 확장 개방
Application은 JDBC Interface를 중간에 둬서 내부적으로 하나의 통로만 가지고 있고,
외부적으로 N개로 개방적으로 확장이 가능하도록 되어있다.
3. LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
서브 타입은 언제나 자신의 기반(상위) 타입으로 교체할 수 있어야 한다.
소나타/그랜저는 아반떼가 될 수 없다.
정찰기/수송기는 공중 유닛/비행기가 될 수 있다.
4. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다!
자동차 내비는 자동차 길 안내(인터페이스)만 상속받으면 되는데,
"지도"를 상속받으면 도보안내/자동차안내/바이크안내... 등 다른 쓸데없는 기능들을 상속받게 된다.
5. DIP(Dependency Inversion Principle) : 의존 역전 원칙
자신보다 변하기 쉬운 것에 의존하지 말아야 한다.
사람은 옷에 의존할 수는 있지만,
옷은 변하기 쉽다(여름/봄/가을)
사람이라는 객체에
옷이라는 인터페이스를 주고
여름 옷/봄 옷/가을 옷이 옷이라는 인터페이스에 의존하게 된다.
의존의 역전!
POJO JAVA
POJO ( Plain Old Java Object ) : 순수한 자바 오브젝트
EJB를 많이 사용하던 시절에는 단순한 자바 오브젝트 사용이 아니라 EJB에 종속적인 부분으로 개발 진행
그로 인해 모듈 교체/시스템 업그레이드 시 종속성으로 인하여 불편함 발생
* EJB 뜻
- Enterprise JavaBeans
- 미국의 Sun Microsystems 회사에서 제창한 규약
- 기업환경의 시스템을 구현하기 위한 서버측 component model
- 대규모 분산 객체 시스템을 구 축하기 위한 기술
포조 특징
1.특정 규약에 종속되지 않는다.
특정 라이브러리, 모듈에서 정의된 클래스를 상속받아 구현하지 않아도 된다.
외부의 의존성을 두지 않고, 순수한 자바로 구성 가능해야 한다.
2.특정 환경에 종속되지 않는다.
비즈니스 로직을 처리하는 부분에, 외부 종속적인 http request/session 등 POJO를 위배한 것임.
@Annotation 기반으로 설정하는 부분도 엄연히 POJO 위배
포조 프레임워크
- Spring / Hibernate
하나의 서비스를 개발하기 위해서는, 비즈니스 로직/시스템의 복잡함 등 다양한 어려움을 맞이하게 되는데...
두 프레임 워크는 객체지향적인 설계/POJO 지향하고 있다.
그러므로 개발자가 서비스 로직에 집중/POJO로 쉽게 개발할 수 있도록 지원!
마지막으로!
1. 자신의 코드에 if/else, switch가 난무하고 있지 않은가?
2. 책임과 역할이 다른 코드가 하나의 클래스에 다 들어가 있지 않은가?
3. 절차지향적으로 한 개의 파일에 모든 코드를 넣고 있지 않은가?
4. 내가 만든 객체가 재사용이 가능한가?
확인하기!
'Spring' 카테고리의 다른 글
| Spring Boot REST API_PUT Method (0) | 2022.04.18 |
|---|---|
| Spring Boot REST API_POST Method (0) | 2022.04.12 |
| Spring Boot REST API_Get Method (0) | 2022.03.22 |
| WEB 개발 개론 (0) | 2022.03.09 |
| CH02.디자인 패턴 (0) | 2022.03.08 |
