JAVA. OOP - 객체지향프로그래밍

 

◆ OOP(Object Oriented Programming)

- 객체지향 프로그래밍 방식

- 큰 문제를 작게 쪼개는 것이 아니라, 작은 문제들을 해결하는 객체를 만드는 방식

 

 

◆ OOP의 장점과 단점

- 장점 : 코드의 재사용성, 유지보수, 코드 간결

- 단점 : 처리시간이 비교적 오래 걸림(JMV도 거치니까), 프로그램 설계 많은 고민과 시간 투자.

 

 

◆ OOP의 4가지 특징

 

1. 추상화(Abstraction)

- 불필요한 정보는 숨기고, 중요한 정보만 표현하여 프로그램을 간단하게 만드는 것
  (중요한 정보란? 각 객체들의 공통된 특성을 의미)

- 각 객체의 구체적인 개념보다 추상적 개념에 의존해야 설계를 유연하게 변경 가능

 

2. 캡슐화(Encapsulation)

- 객체의 필드, 메소드를 하나로 묶고, 실제 구현 내용을 감추는 것(캡슐처럼 묶어서 보관)

- 외부 객체는 객체 내부 구조를 알지 못하며 객체가 노출해 제공하는 필드, 메소드만 이용 가능!

- 클래스 내부 구현의 응집도를 높이고, 외부 클래스와의 결합도를 낮춤

- 목적 : 객체 내부의 무결성을 유지함으로써 보안을 유지하기 위함이다.

            (무결성을 유지하기 위해 접근제한자를 사용한다!)

 

<접근제한자의 종류>

ex) public, private, protected, default
public : 클래스 외부에서 접근 가능
private : 클래스 내부에서만 접근 가능
protected : 상속받은 자식 클래스에서만 접근 가능

 

<참고> 응집도와 결합도

 - 응집도(Cohesion) : 클래스나 모듈 안의 요소들이 얼마나 밀접하게 관련되어 있는지를 나타냄
 - 결합도(Coupling) : 어떤 기능을 실행하는 데 다른 클래스나 모듈들에 얼마나 의존적인지를 나타냄

 

 

3. 상속성(Inheritance)

- 상위 클래스의 필드와 메소드를 물려받아 하위클래스에서 사용

- 하위클래스는 상위 객체를 확장하여 추가적인 필드와 메소드를 가질 수 있음

- 아래로 내려갈수록 구체화(specialize), 위로 갈수록 일반화(generalize)

 

※ 상속의 효과

- 상위 객체를 재사용해서 하위 객체를 빨리 개발 가능

- 반복된 코드의 중복을 줄임

- 유지보수의 편리성 제공

- 객체의 다형성 구현 (★★★ 상속성 - 다형성의 필수 조건이다!!)

 

 

4. 다형성(Polymorphism)

먼저, 비유를 통해 다형성에 대해 다가가보자!

 

부모객체(동물 - sound메소드)를 상속받는, 자식객체(강아지, 고양이)가

부모의 메소드를 상속 받았을 때 자식객체의 sound가 각각 다른 실행 결과가 나타난다.

 

- 하나의 메소드나 클래스가 다양하게 동작하여 다른 결과를 내는 것(Overloading, Overriding)

- 부모 타입에는 모든 자식 객체가 대입 가능

- 인터페이스 타입에는 모든 구현 객체가 대입 가능

Overloading : 동일한 클래스 내에서 같은 이름의 메소드가 파라미터의 개수나 타입에 따라 다른 기능을 하는 것
Overriding : 부모 클래스의 메소드를 자식 클래스의 용도에 맞게 재정의하여 코드의 재사용성을 높임

 

 

※ 다형성의 효과

- 객체를 부품화시키고 부품화된 객체들을 조립 가능하게 한다.

- 일관된 인터페이스(약속) 제공

- 유지보수 용이

- 재사용성 가능

 

 

◆ OOP 설계 원칙

※ 참고 사이트 https://www.nextree.co.kr/p6960/

두문자	약어	개념
S	SRP	단일 책임 원칙(Single Responsibility Principle) - 한 클래스는 한 가지 종류의 책임(하나의 개념)만 가져야 한다.  - 클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 함을 의미한다. "1인분만 단위로 생각하자! 1인분들을 모아서 리트스화하면 된다!!"
O	OCP	개방-폐쇄 원칙(Open/Closed Principle) - 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다. - 기존 구성요소를 수정/변경하기보단 기존 구성요소를 확장해서 재사용해야 한다. "기존 프로그램에 문제가 생기지 않도록!! 우회하는 방향으로 확장!!" "
L	LSP	리스코프 치환 원칙(Liskov Substitution Principle) - 서브타입(하위)은 언제나 기반타입(상위)으로 대체(호환)할 수 있어야 한다. - 선언은 기반 클래스로, 생성은 구체 클래스로 대입한다(IS-A관계로 제한). "다형성으로 인한 확장효과를 얻기 위해 지켜야 할 규칙!!"
I	ISP	인터페이스 분리 원칙(Interface Segregation Principle) - 클라이언트는 자신이 사용하지 않는 메소드와 의존관계를 가지지 않도록 해야 한다. - 어떤 클래스가 종속될 때에는 가능한 최소한의 인터페이스만을 사용 해야 한다. "인터페이스의 단일 책임을 강조! 인터페이스를 분리해라!"
D	DIP	의존관계 역전 원칙(Dependency Inversion Principle) - 고차원 모듈은 저차원 모듈에 의존하면 안된다. - 기초클래스는 하위클래스가 누군지 몰라야 한다. "복잡한 컴포넌트 간의 커뮤니케이션 관계를 단순화하기 위한 원칙!"

 

 

---

 

객체지향을 공부 할 때 문법 보다는 개념과 원리를 이해는 것이 우선.

그래야만 객체지향적으로 사고할 수 있으며 보다 유연하고 안정적인 프로그램을

설계 할 수 있는 능력을 배양 할 수 있다. 

 

Don't Repeat Yourself!

반복하지 마라!