좋은 객체 지향 프로그래밍이란? (다형성.. SOLID 원칙..)

객체 지향 프로그래밍은 프로그램을 유연하고 변경 용이하게 만든다!

 

* 자바 언어의 다형성(Polymorphism)

- 역할과 구현으로 구분해보자

ex) 운전자 - 자동차

운전자는 자동차의 종류가 바껴도 운전을 할 수 있다. 자동차의 자세한 내부 구조라던지.. 이런건 신경 안써도 된다!

---

역할과 구현을 분리?

- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.

- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.

- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.

- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

 

---

- 자바 언어의 다형성을 활용

   - 역할 = 인터페이스

   - 구현 = 인터페스를 구현한 클래스, 구현 객체

- 객체를 설계할 때 역할과 구현을 명확히 분리

- 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

 

---

객체의 협력이라는 관계부터 생각

- 혼자 있는 객체는 없다.

- 클라이언트 : 요청,  서버 : 응답

- 수많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다

 

---

다형성의 본질!!

- 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다

 

---

** 역할과 구현을 분리 정리

- 유연하고 변경이 용이

- 확장 가능한 설계

- 클라이언트에 영향을 주지 않는 변경 가능

- 인터페이스를 안정적으로 잘 설계하는 것이 중요!!

 

---

스프링과 객체 지향

- 다형성이 가장 중요하다!

- 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다

- 스프링에서 이야기하는 제어의 역전(IOC), 의존관계 주입(DI)은 다형성을 활용해서 역할 구현을 편리하게 다룰 수 있도록 지원한다.

- 스프링을 사용하면 마치 레고 블럭 조립하듯이, 공연 무대의 배우를 선택하듯이, 구현을 편리하게 변경할 수 있다

 

---

좋은 객체 지향 설계의 5가지 원칙 (SOLID) ******

 

• 단일 책임 원칙(Single 어쩌고 저쩌고..)

모든 클래스 즉, 하나의 클래스는 하나의 책임(기능)만 가진다!

예) 자동차(클래스) -----> 시트, 엔진,..........등등 엄청난 세부 기능이 많은데, 이걸 자동차의 하나의 클래스에 다 넣지말고, 각각 분리하여 의존관계로 정의할 것! 

 

• 개방/폐쇄 원칙(Open/Closed 어쩌고 저쩌고)

클래스가 확장에는 개방되어있고, 수정에는 닫혀있어야한다!

즉, 어떤 기능을 추가할 때 기존 코드를 변경하지 않고도 기능을 추가할 수 있어야한다.

클래스 생성할때 상속을 받아서 기존 코드는 그대로!

public class Calculator {
	
	//사각형 넓이 구하는 함수
	public float RectangleArea(Rectangle rectangle) {
		return rectangle.width * rectangle.height;
	}
	
	//원 넓이 구하는 함수
	public float CircleArea(Circle circle) {
		return circle.width * circle.height;
	}
	
	//오각형 넓이 구하는 함수..
	//도형 추가될때마다 Calculator 클래스가 수정되어 Calculator를 참조하는 다른 클래스에 문제가 될 수 있다!
	
}

 

개방 폐쇄 원칙을 따른 코드

public abstract class Shape { // Shape 추상 클래스를 생성하여
	public abstract float CalculateArea(); // 넓이 구하는 함수를 따로 만든다
}

public class Rectangle extends Shape { // Shape 상속받은 사각형 클래스 따로 빼기
	public float width;
	public float height;
	
	@Override
	public float CalculateArea() { //넓이는 따로 오버라이딩하여 구현 (이렇게 해야 도형이 추가되어도 기존의 코드는 변경되지 않는다)
		return width * height;
	}
}
public class Circle extends Shape { // Shape 상속 받기
	public float radius;
	
	@Override
	public float CalculateArea() { 
		return radius * radius * 3.14;
	}
}

 

• 리스코프 치환 원칙(Liscope 어쩌고 저저고)

상위 타입을 객체를 사용하다가, 이거를 상속받은 하위 객체를 사용을 해도 정상 작동해야한다!

 

• 인터페이스 분리 원칙(Interface 어쩌고 저쩌고)

하나의 일반적인 인터페이스 보다는 여러개의 구체적인 인터페이스를 사용한다! 

 

• 의존 역전 원칙(Dependency Inversion 어쩌고 저쩌고)

의존관계를 맺을때 좀더 일반적이고 추상적인것에 의존해야한다!

즉, 하위 개념이 아니고 좀 더 상위개념, 추상화된것을 의존하는것이 좋다!