# Principle

## Principle이란

* 어떤 사물이나 현상의 근거가 되는 보편적 진리
* 이미 많은 경험과 실험에 의해 증명되었기 때문에 별도의 수식으로 증명할 필요 없음

## Code Principle

> 작은 단위의 코드에 적용되는 클린코드 원칙

{% hint style="warning" %}
해당 원칙들은 코드를 작성할 때 보편적으로 유용한 경험 법칙이 될 수 있지만, 모든 상황에서 무조건 따라야한다는 아님, 항상 이유(why)를 생각하면서 언제 원칙을 지키지 않아도 되는지 생각하는 것이 더 중요
{% endhint %}

###  KISS (Keep It Simple, Stupid)

바보처럼 단순하게, 즉 불필요한 복잡성을 줄이고 최대한 단순하고 간결하게 만들어라 

복잡성, 속도 비용 측면에서 가장 단순한 방법이 가장 좋은 경우가 많다는 것을 의미

{% hint style="info" %}
단순성이란 최소한의 부품으로 부품 간의 상호 작용을 최소화하는 것을 의미
{% endhint %}

### DRY (Don't Repeat Yourself)

> 같은 일을 반복해서 하지마라

반복되는 기능이나 객체를 하나로 만들어 관리함으로써 변경사항이 생길 때 연쇄적으로 전파되는것을 방지한다.

{% hint style="warning" %}
코드의 형식이 비슷하지만 코드의 목적이 다른 경우는 분리해야 한다.

즉, 변경사항이 생길 때 같은 이유로 변경이 되어야한다.
{% endhint %}

### YAGNI (You Ain't Gonna Need It)

> 야! 그거 아직 필요없어!

현재 해결할 필요가 없는 상황이나, 요구사항을 해결하기 위한 솔루션의 오버 엔지니어링을 방지하는데 자주 사용된다.

* 현재 필요하지 않는 기능 ❌
* 현재 사용하지 않는 기능 ❌
* 지나치게 미래 지향적 ❌

### Leblance's Law (르블랑 법칙)

> Later equals never 나중은 결코 오지 않는다.

* 한번 작성한 쓰레기 코드를 나중에 수정하는 일은 결코 없다

## SOLID

> 객체지향 프로그래밍에서 소프트웨어를 개발할 때 확장성, 유지보수성, 유연성을 위한 5가지 원칙을 앞 글자만 따서 명명한 원칙
>
> "Uncle Bob" 이라 불리는 [Robert C. Martin](https://en.wikipedia.org/wiki/Robert_C._Martin).에 의해 널리 알려지게 됨

### SRP (Single Reponsibility Principle)

> **단일 책임 원칙** - 각 클래스는 하나의 책임만을 가지게 만들어야 된다.

여러 책임을 갖고 있을 때, 하나의 동작이 변경이 되면 다른 동작에 영향을 끼쳐 버그가 발생할 확률이 늘어나게 됨

단일 책임 원칙은 각 책임을 분리하여 동작이 변경되었을 때 다른 동작에 영향을 미치지 않도록 하는것을 목표로 함

### OCP (Open Closed Principle)

> **개방 폐쇄 원칙** - 클래스는 확장에는 열려 있고 변경에는 닫혀 있어야 한다

클래스의 동작을 변경하면 해당 클래스를 사용하는 모든 곳에 영향을 미치게 된다.

개방 폐쇄 원칙은 클래스가 사용되는 모든 곳에서 버그가 발생하지 않도록, 기존 동작을 변경하지 않고 확장하는 것을 목표로 함

### LSP (Liskov **Substitution** Principle)

> **리스코프 치환 원칙** - 인터페이스의 서브타이핑은 인터페이스에 정의된 형태를 최대한 유지해야 한다\
> 즉, 자식 클래스는 부모 클래스와 동일한 요청을 처리하고, 동일한 유형의 결과를 반환해야 한다.

리스코프 치환 원칙은 자식클래스와 부모클래스가 동일한 방식으로 사용될 수 있도록 일관성을 지키는 것을 목표로 함

### ISP (Interface Segregation Principle)

> **인터페이스 분리 원칙** - 인터페이스는 최소한의 메소드만으로 유지해야 한다.

클래스는 자신의 역할을 수행할 액션만을 수행해야 한다.

인터페이스 분리 원칙은 큰 인터페이스를 작은 인터페이스로 분리하여 클래스가 클라이언트가 필요로 하는 인터페이스만을 제공할 수 있도록 하는 것을 목표로함

### DIP (Dependency Inversion Principle)

> **의존 관계 역전 원칙** - 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안된다. 둘다 추상화에 의존해야 함

하위 레벨 모듈(도구)는 분리하여 인터페이스를 통해 관리 되어야 한다.

죽, 클래스와 인터페이스 모두 도구의 작동 방식을 알 수 없어야 한다

의존 관계 역전 원칙은 인터페이스를 통해 하위 레벨의 모듈에 대한 상위 레벨의 모듈의 의존성을 낮추는 것을 목표로 함

{% hint style="info" %}
상위 레벨 모듈(고 수준) → 도구로 액션을 실행하는 모듈

하위 레벨 모듈(저 수준) → 작업을 실행하는데 필요한 도구
{% endhint %}