[JAVA] 객체지향 5대원칙 / POJO JAVA

📌 SRP Single Responsibility Principle 단일 책임 원칙

클래스는 하나의 일에만 책임진다.

즉, 1개의 클래스에 하나의 역할만 가져야한다.

설계중인 프로그래밍에 클래스가 여러가지 역할을 가지고 있다면 검토 후,

불필요한 필드나 메소드를 제거해야한다.

 

기능이 너무 많은 FTP Client 클래스

 

예를들어 FileReader(String str)로 쓰이다가 -> FileReader(File file)로 매개변수 객체를 바꾸면 

외부에서 쓰이고있던 FileReader는 변경이되었기때문에,

FTP Client와 FileReader 또한 수정해줘야한다.

.

.

이 밖에도, FTP Client는 너무 많은 기능을 가지고 있다. 

각각을 분리시킬 필요가 있다. 

 

 

 

Network Connection, File Writer, File Reader를 각각 분리시킴

 

그렇게 되면 다른 새로운 모듈 (Local File Reader, HttpClient)이

추가 및 수정 되더라도 영향 받지 않기 때문에 유지보수, 재활용이 쉬워진다.

 

 

---

 

📌 OCP Open Closed Principle 개방 폐쇄 원칙(오픈/클로즈원칙)
자신의 확장에는 열려있고 주변의 변화 대해서는 닫혀있어야한다. 

제공되는 기능은 확장할 수 있지만(오픈), 수정에 영향을 받지 않는 (폐쇄성)임을 고려한다.

 

다형성을 예로,

슈퍼클래스와 그 서브 클래스가 미래에 어떤 확장과 수정된 방식(메소드 내용 변경 등)을 해도 

사용자 측은 그 수정에 대해 영향을 받지 않아야 한다.

 

하지만, 수정이 생기면 그에 따른 변화는 반드시 생긴다.

이 문제를 어떻게 해결하나?

 

객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

상위클래스 또는 인터페이스를 중간에 둠으로써, 

자신은 변화에 대해서는 폐쇄적이지만, 인터페이스는 외부의 변화에 대해서 확장을 개방해줄 수 있다. 

 

대표적으로 JDBC와 Mybatis, Hibernate 등 JAVA에서는 Stream에서 찾아볼 수 있다.

JDBC 인터페이스

 

 

어플리케이션 입장에서는 외부적으로 많은 Database가 있을 수 있다.

Database가 늘어날 수록 계속 변경되는 상황이 있을 수 있는데, 

이를 방지하기 위해서 JDBC 인터페이스가 있다. 

 

어플리케이션 내부적으로는 한 하나의 통로인 JDBC 인터페이스만을 가지고 있지만,

JDBC 인터페이스 외부적으로는 N개 이상으로 확장할 수 있다. 

 

 

 

---

📌 LSP(Liskov Substitution Principle) 리스코프 치환원칙
서브타입은 언제나 자신의 기반(상위) 타입으로 교체할 수 있어야한다

하지만 여기서 하위 클래스가 중요하게 지켜야할 것은

자신의 상위 타입(인터페이스)의 규약을 다 지켜야한다는 점이다.

다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.

단순한 컴파일 패스를 넘어서는 이야기다. 

예를들어, 자동차 인터페이스의 엑셀을 앞으로 가라는 기능이다. 

하지만 이 기능을 하위클래스에서 뒤로 가게 구현하면 LSP가 위반된다. 

엑셀 기능은 느리더라도 반드시 앞으로 가야한다.

 

추가 ) 상위는 하위를 포괄하는 일반적 개념을 가지고 있어야 한다.

포유류 - 인간 의 개념에서 인간은 언제나 포유류에 속하는 것을 떠올리면 된다.

슈퍼클래스에서 구현 가능한 것은 서브클래스로 대체 작동이 가능한지 고려해야한다.

 

---

📌 ISP (Interface Segregation Principle) 인터페이스 분리원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다. 

클라이언트가 원하지 않는 메소드를 강요해서는 안된다는 의미이다. 인터페이스에 정의되어 있는 것은 구현하는 클래스에서 모두 구현해야 하며, 그 안에 알맞지 않은 메소드가 포함된 경우, 설계가 망가질 가능성이 있다. 

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

 

지도라는 객체는 에는 도보안내, 자동차 전용길 안내, 자전거 전용길 안내, 지하철 노선 등등 많은 기능이있을 수 있다.

이때 지하철 어플을 만들 때, 지도를 상속받으면 다른 필요없는 자동차 전용길 안내까지 구현해야하는 불필요성이 생긴다. 따라서 도보안내, 자동차 전용길 안내에 따른 인터페이스를 각각 만들자는 것이 인터페이스 분리원칙이다.

 

 

---

📌 DIP (Dependency Inversion Principle)의존 역전 원칙
자신보다 변하기 쉬운 것에 의존하지 말아야한다.

기본 역할에 의존해야지, 구체화에 의존하면 안된다는 것이다.

(슈퍼 클래스는 서브 클래스에 의존한다.)

 

사람은 옷에 의존할 수 있다.

여성옷, 봄 옷, 남성옷이 아니라, '옷'에 의존한다.

자신보다 변하기 쉬운 것에 의존하지 않기 위해 중간에 interface로 '옷' 객체를 끼워넣기.

 

이는 Open Closed Principle 개방 폐쇄 원칙과 비슷한 원리이다.

원래 SOLID 는 객체 지향 4대 특성에 기반함으로써 서로 유사한 모양과 의미를 담과 있다.

 

 

객체 지향의 핵심은 다형성이다.

하지만 다형성 만으로는 쉽게 부품을 갈아 끼우듯 개발할 수 없다.

구현 객체를 변경할 때 클라이언트 코드도 함께 변경되는 상황이 온다. 

다형성 만으로는 OCP, DIP를 지킬 수 없다. 

뭔가가 더 필요하다는 말이다. 

그게 뭘까. 

답은 스프링에 있다.

DI, 의존성 주입이다. 

 

어쨌든,

어떤 원칙이든 바탕에는 "역할을 명확히 해야한다"는 생각은 필수로 가져야 한다.

---

 

 

📌 POJO JAVA란?

 

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

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

특정 Library, Module에서 정의된 클래스를 상속받아서 구현하지 않아도 된다. 

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

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

만일 특정 비즈니스 로직을 처리하는 부분에

외부 종속적인 HTTP REQUEST, SESSION 등 POJO를 위배한 것으로 간주한다.

또한 많이 사용하고는 있지만 @Annotation 기반으로 설정하는 부분도

엄연히는 POJO라고 볼 순 없다.

 

 

POJO Framework
Spring, Hibernate
하나의 서비스를 개발하기 위해서는 

시스템의 복잡함 , 비즈니스 로직의 복잡함 등 다양한 어려움을 맞이하게 된다.
위의 두 프레임 워크는 객체지향적인 설계를 하고 있으며, 또한 POJO를 지향하고 있다.
그러므로 개발자가 서비스 로직에 집중하고 이를 POJO로 쉽게 개발 할 수 있도록 지원하고 있다.

 

 

 

다음 질문들을 잘 기억해보자.

자신의 코드에 if/else , switch가 난무하고 있지않은가?
책임과 역할이 다른 코드 하나의 클래스에 다 들어가 있지 않은가?
절차지향적으로 한개의 파일에 모든 코드를 넣고 있지 않은가?
내가 만든 객체가 재사용이 가능한가?