[OOP] 3️⃣ | 객체지향 프로그래밍 원칙 (SOLID)

getter ? setter ?

객체 지향 프로그램에서 데이터 자체는 외부에서 접근을 할 수 없도록 하고,메소드만 공개해서 유효한 값들을 데이터로 저장한다.➡️ 객체들이 데이터를 외부에 직접적으로 접근하는 것을 막았다

캡슐화를 통해 정보은닉화를 한 값을 얻어내기 위해 접근자 getter와 setter를 이용해 필드에 접근한다.

정보은닉화 되어 있는 age의 값을 가져오기 위해 (노란박스) get을 값을 읽어오고 set으로 값을 사용한 정의를 해주었다.

(핑크박스)

_age는

JS버전의 (접근자)protected를 사용하는 형식이다.

Getter ?

인수가 없는 함수로, 프로퍼티를 읽을 때 동작한다

Setter ?

인수가 하나인 함수로, 프로퍼티에 값을 쓸 때 호출된다

SOLID 원칙 (5가지) ?

소프트웨어 작업에서 소스 코드를 읽기 쉽고 확장하기 쉽게 될 때까지 코드리팩토링을 위한 지침이다설계가 올바르게 되었는지를 확인하는 하나의 기준과 가이드라인이다

SRP | 단일 책임 원칙 (Single responsibility principle) ?

모든 클래스는 하나의 책임만 가져야 한다

• 응집도는 높게 ⬆️ 결합도는 낮게 ⬇️
• 유지보수가 용이하다
• 단순한 개념과 그렇지 못한 어려운 설계
• 클래스는 그 책임을 완전히 캡슐화해야한다(관계복잡도를 줄임)
• 클래스 분할을 하여 설계한다 (책임영역 확실)➡️ 클래스간의 유사한 책임이 주어진다면 부모클래스 사용

![https://velog.velcdn.com/images%2Fjaewon97%2Fpost%2F7fea6ce5-36b1-4563-93d6-0e4dd8b39661%2Fimage.png](https://velog.velcdn.com/images%2Fjaewon97%2Fpost%2F7fea6ce5-36b1-4563-93d6-0e4dd8b39661%2Fimage.png)

### OCP | 개방 폐쇄 원칙 (Open Closed Principle) ?

> 소프트웨어 구성요소(클래스, 모듈, 함수 등등)확장에는 열려있고, 변화에는 닫혀있다
> 

• 다른 추가 상황이 일어나더라도 기존 구성은 변하지 않는다
• 유연성, 재사용성, 유지보수성에 강하다
• 코드를 매번 수정하지 않고도 새로운 상황에 적응할 수 있도록 대응해야 한다
• 이를 적용하기 위해서는 Interface 또는 추상화에 의존하도록 설계되어야 한다➡️ 변경 될것과 변경되지 않을 것을 엄격하게 분리하고, 만나는 지점에서 인터페이스를 정의한다(구현에 의존하기 보다는 정의한 인터페이스에 중점으로 코드 작성)

LSP | 리스코프 치환 원칙 (Liskov Substitution Principle) ?

서브타입. 즉, 자식 클래스는 언제나 부모클래스를 대체할 수 있어야 한다

• 자식클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야한다
• 자식클래스가 부모클래스를 오버라이딩하거나 추가적인 기능을 통해 부모의 상태를 변경시키는 것은 LSP원칙을 위반하는 것!

![https://velog.velcdn.com/images%2Fjaewon97%2Fpost%2F74c116da-920a-4f05-8b42-ee4aa019abea%2Fimage.png](https://velog.velcdn.com/images%2Fjaewon97%2Fpost%2F74c116da-920a-4f05-8b42-ee4aa019abea%2Fimage.png)

ISP | 인터페이스 분리 원칙 Interface Segregation Principle) ?

클라이언트 자신이 이용하지 않는 기능(메서드)에 영향(의존관계)을 받지 않아야 한다

• 상위 클래스는 풍성할 수록 좋고, 인터페이스는 작을수록 좋다인터페이스 (= ~할 수 있는(is able to)) 분할 원칙의 핵심

예를들어, 복합기를 사용할 때 복사를 하고 싶은사람과 프린트를 하고 싶은사람, 팩스를 보내고 싶은 사람 등 복합기가 다양한 기능을 제공하고 있지만 본인이 원하는 기능만이 작동하며 자신이 이용하지 않는 기능에 대해서는 영향을 받지 않는다

즉 인터페이스를 클라이언트에 특화 되도록 분리시키는 설계 원칙이라고 할 수 있다

DIP | 개방 폐쇄 원칙 (Open Closed Principle) ?

컴퍼넌트 간의 커뮤니케이션이 복잡하고, 비효율적일 경우 사용된다

• 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것에는 의존하지 않기변화하기 어려운 것, 거의 변화가 없는 것에 의존해야한다
• 고차원 module/class는 저차원 module/class에 의존하면 안된다(부모 classs는 자식 class에 의존해서는 안된다)

이미지와 같이 자동차는 스노우타이어, 일반타이어, 광폭타이어와 같은 디테일한 개념보다, 타이어라는 추상화된 개념에 의존하도록 설계되어야 한다.

IOC | (Inversion of Control) ?

객체 간 결합도를 줄이기 위해 제어를 역전시키는 개념

• IOC는 GOF 디자인 패턴 저자의 논문에서 처음 발견 되었다
• 전통적인 프로그래밍에서 흐름은 작성된 프로그램이 외부 라이브러리의 코드를 호출해 이용한다BUT 제어 반전이 적용된 이 구조에서는 외부 라이브러리의 코드가 프로그래머가 작성한 코드를 호출한다.➡️ 프로그래머가 작성한 프로그램이 재사용 라이브러리의 흐름 제어를 받게 되는 소프트웨어 디자인 패턴을 말한다