스프링을 배우기 전에 객체 지향에 대한 이해가 필요하다고 한다. 자바 학습 시 배웠었고 (추가 강의를 통해) 학습 예정이지만 한번 더 짚고 넘어가기로 했다
객체지향이란
현실에 존재하는 사물을 있는 그대로 모델링하여, 이들의 행위와 속성을 정의하고, 절차적이 아닌 객체가 중심이 되어 실제 사물이 동작하는 방식으로 설계
- 사물 자체 = 객체(Object), 사물의 행위 = 행위(Method), 사물의 속성 = 변수(Variable)라고 정의
- 절차지향 언어의 비효율을 극복하기 위해 채택
- 추상화,상속,은닉,재사용,인터페이스 등의 특성이 있음
(예시) 자동차 - Object = 자동차 - Variable = 자동차명, 번호, 등록연월 등 - Method = 주행거리, 연비계산, 번호교체 등
객체의 3요소
- 상태 유지 (객체의 상태)
객체는 상태 정보를 저장하고 유지해야하며 이런 속성(Variable)은 변수로 정의되어야 함
속성이 변경되면 객체 상태도 변경될 수 있어야 함
- 기능 제공 (객체의 책임)
객체는 기능을 제공해야하며 이는 메소드(Method)의 제공으로 이뤄짐
외부로부터 직접 속성에 접근하는 것이 아닌 객체가 제공하는 메소드로 변경할 수 있도록 해야 함
- 고유 식별자 제공 (객체의 유일성)
객체는 고유한 식별자를 가져야 함(이후 DB에서 Unique Key 또는 Primary Key로 작성 가능)
물리 객체와 개념 객체
- 물리 객체: 실제로 사물이 존재하며 이를 클래스로 정의한 것
(예시) 렌트카 시스템 자동차, 고객, 직원, 사업장, 정비소 등
- 개념 객체: 웹 시스템의 서비스에 해당하며, 비즈니스 로직을 처리하는 부분을 말함. 비즈니스 로직에서는 여러 객체를 서로 상호작용 하도록 하며, 객체가 제공하는 오퍼레이션(Method)를 통해 객체의 속성을 변경함
(예시) ATM 시스템 사용자(Object)의 액션에 따라 계좌(Object)의 잔고 속성을 변경하는 입출금 로직
객체지향의 특성 4가지
1. 캡슐화
객체의 속성(Variable)을 보호하기 위함
- 자신의 속성을 변경할 수 있는 기능(Method)를 제공해야 함
- 각 속성의 상대되는 기능을 제공해야 함 (예시) 차량의 대여/반납, 자동차 등록/해지
- 객체 안의 기능은 객체 안의 속성을 처리해야 하며, 다른 객체를 전달받아 해당 객체에 정의된 속성을 처리하면 안된다. (객체의 형태가 아닌 매개변수(parametor)의 형태로 전달되어야 한다)
(예시) - Getter/Setter 외부에서 내부 속성에 접근할 수 있도록 하기 위해 사용 - CRUD 데이터 처리를 위한 기본 기능 - Business Logic 비즈니스 로직 처리 기능 - 객체 생명주기 destroy(), disconnect() 등 소멸에 대한 처리 기능 - 객체 영구성 관리 영구성(유효성)에 대한 변경이 필요한 경우 외부에서는 접근이 불가능하도록 private로 선언하며, 내부의 다른 기능을 통해 사용되도록 한다
장점
유지보수가 쉽다
- 추상화 제공: 메소드가 어떻게 동작하는지 외부에서는 알 수 없음
- 재사용성 향상: 객체의 모듈성과 응집도 상승
- 무결성 보장: (getter/setter 제외하고) public method는 입력된 매개변수를 먼저 확인(Validation)한 후 실행함
2. 상속
상속의 효과
- 프로그램 구조 이해: 최상위 클래스 구조를 보고 하위 클래스 동작 이해 가능
- 재사용성 향상: 클래스를 생성할 때마다 필요한 속성 및 메소드를 모두 정의하지 않아도 된다
- 확장성 향상: 일관된 형태의 객체를 추가할 수 있음
- 유지보수성 향상: 일관된 형태로 수정 가능
3. 다형성
하나의 개체가 여러 개의 형태로 변화하는 것. 오버라이딩(Overiding)을 통해 가능함
4. 추상화
객체지향에서 추상화는 모델링을 말한다. 공통적인 부분 또는 특정 특성을 분리해서 재조합하는 것
- 다형성,상속 등이 추상화에 해당한다
객체지향 설계 5원칙 SOLID
좋은 소프트웨어 설계를 위해 결합도(coupling)는 낮추고, 응집도(cohesion)는 높여야 한다
- 결합도: 모듈(클래스)간의 상호 의존 정도를 나타내는 지표. 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어 객체의 재사용 및 유지보수가 유리하다
- 응집도: 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용 및 유지보수가 용이
1. 단일 책임 원칙(SRP, Single Responsibility Principle)
클래스를 변경하는 이유는 한가지여야 한다. 즉, 클래스의 응집도가 높아야 한다
2. 개방 폐쇄 원칙(OCP, Open Closed Principle)
상위 클래스 또는 인터페이스를 중간에 둠으로써 자신은 변화에 폐쇄적이지만 인터페이스는 외부의 변화에 대한 확장성을 확보할 수 있다
3. 리스코프 치환 원칙(LSP, Liskov substitution Principle)
서브 타입은 언제나 자신의 상위 타입으로 교체할 수 있어야 함
4. 인터페이스 분리 원칙(ISP, Interface segregation Principle)
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺지 않아야 한다. 프로젝트 요구사항과 설계에 따라 SRP 또는 ISP를 선택한다
5. 의존 역전 원칙(DIP, Dependency Inversion Principle)
자신보다 변하기 쉬운 것에 의존하지 않아야 한다
POJO JAVA (Plain Old Java Object)
(외부 종속성이 없는) 순수한 자바 오브젝트를 뜻한다
- 모듈의 교체, 시스템 업그레이드 시 종속성으로 인한 불편함에서 자유로울 수 있다
- 특정 규약에 종속되지 않음. 특정 라이브러리나 모듈에서 정의된 클래스를 상속받아서 구현하지 않아도 된다
- 특정 환경에 종속되지 않음. 외부 종속적인 http request, session 등을 사용한다면 POJO를 위배한 것으로 간주한다
- Spring과 Hibernate는 객체지향 설계와 POJO를 지향하고 있다