01. 객체지향

객체의 3가지 요소

1. 상태유지 (객체의 상태) : 객체는 상태 정보를 저장하거나 유지할 수 있고, 이러한 속성을 변수로 정의할 수 있다. 이 때 속성이 바뀜으로서 객체 상태가 변경이 될 수 있다.
2. 기능 제공 (객체의 책임) : 기능을 제공한다는 말은 method를 제공한다는 말과 같다. 캡슐화를 이용하고 외부 접근이 불가능하도록 구현하여야 한다.
3. 고유 식별자 제공 (객체의 유일성) : 고유값을 가져야 한다.

개념 객체

이후 우리가 개발할 웹 시스템에서 service에 해당된다. business logic을 처리하는 담당이다. 

여러 객체를 서로 상호작용하도록하여 객체가 제공하는 operation method를 통하여 객체의 속성을 변경시킨다.

 

객체 지향의 4대 특성

캡슐화 

• 객체의 속성을 보호하기 위해서 사용된다. method를 설계하는데 getter/setter, CRUD(데이터 처리), business logic, 생명주기처리(destory(), disconnection()과 같은 소멸에 대한 method), 영구성 관리(외부 접근 불가능, private으로 선언) 등 method가 있다.
• 실제로 method가 어떻게 동작하는 지는 외부에서 이해할 필요가 없다. 단순 호출로 인해 해당 기능이 실행 가능하고, 이를 통해 객체 단위로 프로그램 설계가 가능하다.
• 재사용성도 향상된다. 캡슐화 형태로 제공됨으로 객체의 모듈성과 응집도가 높아지기 때문이다.
• 유지보수 효율성 향상
• 무결성 : 캡슐화 코딩 - 주로 변수는 private으로 선언, method를 public으로 선언한다. 이는 객체의 무결성을 위해서이다. getter/setter 를 제외하고는 public method는 입력된 매개변수를 validation한 후에 실행하는 것을 기본으로 한다. validation을 통해 객체의 값을 바꾸거나 값에 대한 유효성을 가질 수 있다.

상속

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

다형성

• 다형성은 하나의 객체가 여러 개의 형태로 변화 하는 것을 말하며, 이를 객체지향에서도 유사하게 사용하고 있다.
• 다형성을 하기 위해서는 오버라이딩을 통해서 가능하다. (오버라이딩 : 부모 클래스 메소드를 자식 클래스에서 재정의)

추상화

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

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

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

- 결합도 : 모듈(클래스)간의 상호 의존 정도를 나타내는 지표로써 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어서 객체의 재사용 및 유지보수가 유리하다.

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

 

• SRP(Single Responsibility Principle) 단일 책임 원칙 : 어떠한 클래스를 변경해야 하는 이유는 한가지 뿐 이여야 한다.
• OCP(Open Closed Principle) 개방 폐쇄 원칙 : 자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다. 상위 클래스 또는 인터페이스를 중간에 둠으로써, 자신은 변화에 대해서는 폐쇄적이지만, 인터페이스는 외부의 변화에 대해서 확장을 개방해 줄 수 있다. 이러한 부분은 JDBC와 MyBatis, Hibernate 등 java에서는 Stream(Input, Out)에서 찾아볼 수 있다.
• LSP(Liskov Substitution Principle) 리스코프 치환 원칙 : 서브 타입은 언제나 자신의 기반(상위) 타입으로 교체할 수 있어야 한다.
• ISP(Interface Segregation Principle) 인터페이스 분리 원칙 : 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다. 프로젝트 요구 사항과 설계에 따라서 SRP/ISP를 선택한다.
• DIP(Dependency Inversion Principle) 의존 역전 원칙 : 자신보다 변하기 쉬운 것에 의존하지 말아야 한다.

POJO JAVA

• POJO(Plain Old Java Object) : 순수한 자바 오브젝트. 
• 특정 규약에 종속 되지 않는다. 특정 library, module에서 정의된 클래스를 상속 받아서 구현하지 않아도 된다. 외부의 의존성을 두지 않고, 순수한 JAVA로 구성이 가능해야 한다.
• 툭정 환경에 종속되지 않는다. 만일 특정 비즈니스 로직을 처리하는 부분에 외부 종속적인 http request, session 등 POJO를 위배한 것으로 간주한다. 또한 많이 사용하고는 있지만 @annotation 기반으로 설정하는 부분도 엄연히는 POJO라고 볼 수는 없다.
• POJO Framework(Spring, Hibernate) : 하나의 서비스를 개발하기 위해서는 시스템의 복잡함, 비즈니스 로직의 복잡함 등 다양한 어려움을 맞이 하게 된다. 위의 두 프레임워크는 객체지향적인 설계를 하고 있으며, 또한 POJO를 지향하고 있다. 그러므로 개발자가 서비스 로직에 집중하고 이를 POJO로 쉽게 개발할 수 있도록 지원하고 있다.

 

reference.

github.com/steve-developer/fastcampus-springboot-introduction/tree/master/01.%20%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5