객체지향에 대해 간략한 정리

기존의 c언어와 같은 절차지향으로 프로그램을 작성하다가

현실에 존재하는 사물을 있는 그대로 모델링하여, 행위와 속성을 정의하고, 절차적이 아닌 객체가 중심이 되어

실제로 사물이 동작하는 방식으로 설계하는 방식.

 

객체의 3 요소

상태 유지(객체의 상태)-상태정보 저장, 유지, 속성은 변수로 정의 되어있어야함. 또한 변경가능해야함.

기능 제공(객체의 책임)-메소드로 기능을 제공. 외부로부터 직접 속성에 접근해 변경하는게 아니라 객체의 메소드로 변경가능해야함.

고유 식별자 제공(객체의 유일성)-각 객체는 고유한 식별자 있어야함.(디비에서 유니크키 또는 프라이머리키)

 

물리 객체 : 물리적객체는 실제로 사물이 존재, 이를 클래스로 정의

개념 객체 : 서비스, 비즈니스 로직을 처리하는 부분.

 

객체 지향의 4대 요소

1. 캡슐화 - 객체의 속성을 보호

 컴퓨터의 본체를 킬때 외부의 버튼을 누르지 컴퓨터 메인보드에 직접 전기 신호주는거 아니잖아

-속성이 선언됐는데, 해당 속성을 변경하는 메소드가 없으면 잘못된 속성.

-실물 객체가 가진 기능 모두 제공해야

-각 메소드는 서로 관련이 있어야

-객체 안 메소드는 객체 안의 속성을 다뤄야 하지, 외부 객체를 받아 외부 객체의 속성을 다루면 안됨

-메소드 실행에 필요한 값들은 객체형태가 아닌 매개변수 형태로 전달되어야.

 메소드예시

get/set 으로 속성 접근

crud 데이터 처리를 위한 crud

객체 생명 주기 처리 메소드 destroy, disconnect, quit

장점 

추상화 제공 : 어떤 메소드가 실제로 어떻게 움직이는 지 다 알필요없이 그냥 호출하면ㄷ ㅚㅁ

재사용성 향상 : 모두 캡슐화 형태로 제공되니까 모듈성과 응집도 높음

유지보수 효율

무결성 : 속성을 바로 접근하는게 아니라 메소드에서 요쳥이 유효한지 검사후 실행하므로, 프로그램의 무결성이 올라감.

 

2. 상속

속성의 상속이 아닌 하위로 갈 수록 구체화.

 

3. 다형성

하나의 개체가 여러개의 형태로 변화.

오버라이딩을 통해 가능.

 

4. 추상화

객체지향에서의 추상화는 모델링

공통적인 부분, 특성을 분리해서 재조합하는 부분이 추상화.

 

객체지향 설계 5원칙(SOLID)

결합도는 낮추고 응집도는 높혀라

-결합도 : 클래스 간의 상호 의존정도. 낮아야 객체 재사용 및 유지보수 유리

-응집도 : 한 클래스(모듈) 내부 구성 요소들의 기능적 관련성이 높은 상태.

 

1. SRP 단일 책임원칙 :어떠한 클래스를 변경해야 하는 이유는 한가지 뿐이여야 한다.(속성을 건드리려면 이유는 하나여야 한다.)

2. OCP 개방 폐쇄 원칙 : 자신의 확장에 열려있고, 주변의 변화에 닫혀있어야 한다. (바깥 변화를 유연하게 받아들이고, 내 변화를 드러내지 않고)

3. LSP 리스코프 치환 원칙 : 서브 타입은 언제나 자신의 상위 타입으로 교체 가능해야 한다.(자식 인스턴스는 부모 레퍼런스로 할당 가능해야.)

4. ISP 인터페이스 분리 원칙 : 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다. (인터페이스를 구현할 때, 굳이 내가 구현하지 않을 메소드가 많도록 인터페이스를 만들면 안된다)

5. DIP 의존 역전 원칙 : 자신보다 변하기 쉬운 것에 의존해선 안된다.

 

POJO JAVA

순수한 자바 오브젝트. 모듈 교체나 시스템 업그레이드 다른 라이브러리나 모듈에 의존할 경우 종속성으로 인해 불편함 발생

특정 규약에 종속되지 않고 특정 환경에 종속되지 않고 구현하는 게 특징.

이런 포조를 준수하려 하는게 Spring, Hibernate