객체지향 프로그래밍의 3요소 5원칙!

객체지향의 3요소 5원칙

3요소

캡슐화, 다형성, 상속

Encapsulation 캡슐화

- 프로그램 내에서 같은 기능을 목적으로 작성된 코드를 모아서 다른 곳(클래스)에서 안보이게 숨기는 것.

클래스에 정의된 속성(Attribute)는 숨기고(Private), 객체가 수행할 기능(Function)은 공개(Public)하는 것을 의미한다.

Inheritance 상속

- 클래스 사이에 부모와 자식 클래스가 존재할 수 있다는 뜻.

자식 클래스는 상속받은 부모 클래스의 속성(변수) 및 기능(메소드, 함수)를 물려받는 것을 의미한다.

Polymorphism 다형성

Overriding과 Overloading 두가지로 나뉨.

Overriding

• 부모클래스에서 정의되어 있는 내용을 자식클래스에서 재정의하여 사용하는 것.

Overloading

• 같은 이름을 가진 메소드(함수)를 인자값의 종류에 따라 여러개 만들수 있다.

• 같은 이름의 메소드라고 하더라도, 원하는 기능이 상이할 수 있으니, 메소드가 받는 인자의 종류 또는 숫자를 다르게 하여 기능을 정의하는 것.

5원칙

SOLID

S -> SRP(단일 책임의 원칙 : Single Responsibility Principle)

‘There should never be more than one reason for a class to change’

- 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임(axis of change)을 수행하는 데 집중되어 있어야 한다는 원칙입니다.

- 이는 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 함을 의미합니다.

- SRP 원리를 적용하면 책임 영역이 확실해지기 때문에 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용에서 자유로울 수 있습니다.

- 코드의 가독성 및 유지보수에 있어서 유리합니다.

- 객체 지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초가 되는 원칙입니다.

O -> OCP(개방폐쇄의 원칙: Open Close Principle)

‘You should be able to extend a classes behavior, without modifying it.

- 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원리입니다.

- 이것은 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 가능한 극대화 해야 한다는 의미로, 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며, 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 뜻입니다.

- 재사용 코드를 만드는 기반이며, OCP를 가능하게 하는 중요 메커니즘은 추상화와 다형성.(Written By Robert C. Martin)

객체지향의 장점을 극대화하는 중요한 원리.

L -> LSP(리스코브 치환의 원칙: The Liskov Substitution)

‘FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.’

- 자식 클래스(서브 타입)는 언제나 자신의 부모 클래스(기반 타입)를 대체할 수 있다. 즉, 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 잘 작동해야 한다는 것.

- 상속의 본질인 원리

- 이를 지키지 않을 경우 부모 클래스 본래의 의미가 변해서 is a 관계가 무너짐

I -> ISP(인터페이스 분리의 원칙: Interface Segregation Principle)

‘Client should not be forced to depend upon interfaces that they do not use.’

- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리.

- 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 합니다.

D -> DIP(의존성역전의 원칙: Dependency Inversion Principle)

‘High level modules should not depend upon low level modules. Both should depend upon abstractions.’

‘Abstractions should not depend upon details. Details should depend upon abstractions.’

- 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 의미의역전입니다.

- 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써 관계를 최대한 느슨하게 만드는 원칙입니다.

참고 :

http://www.nextree.co.kr/p6960/

https://namu.wiki/w/%EA%B0%9D%EC%B2%B4%20%EC%A7%80%ED%96%A5%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/%EC%9B%90%EC%B9%99#s-2.3