OOP 개발 원칙

YAGNI - You aren't gonna need it

당장 필요하지 않은 것은 미리 구현하지 말자.

기능이 실제로 필요하기 전까지는 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP) 원칙

처음부터 필요 이상의 기능을 추가하면 설계가 복잡해진다.

또한 실제 해당 기능을 사용하려는 시점에 설계에 변경이 생겨 기존 코드를 다시 재작성해야 해서 일이 더 많아지게 되는 경우가 있다.

KISS - Keep it simple, stupid

단순하게 하라.

처음부터 복잡하게 준비하지 말아야 한다.

가장 단순한 것이 확장하기 쉬운 것이다.

역할에 맞는 적절한 위치의 코드인지, 단순하고 명료해서 타인이 봐도 이해가 쉽게 되는 지를 고민해야 한다.

이 후에 확장해서 쓰려고 할 때 기존 코드를 고치기 힘들거나 많이 고쳐야 한다면 심플하게 시작하지 않아 발생한 문제일 확률이 높다.

설계도 계속 변한다고 생각하고 가장 단순한 구조를 유지 하는 것이 중요하다.

DRY - Don't repeat yourself

같은 일을 두번 하지 말라.

동일한 일을 하는 중복 코드를 만들지 말고 재사용성을 높여야 한다.

YAGNI, KISS 원칙이 우선도가 더 높다.

---

SOLID - Srp, Ocp, Lsp, Isp, Dip

위에 열거한 YAGNI, KISS, DRY는 설계 방향성에 대한 가이드라면 SOLID는 OOP 코드 관리에 대한 가이드로 느껴진다.

Single Responsibility Principle (단일 책임의 원칙)

하나의 클래스는 하나의 책임을 가져야 한다.

만약 특정 기능에 대한 변경을 해야하는데 해당 클래스가 변경해야할 이슈와 다른 역할을 하는 클래스인데 변경 범위안에 들어 있다면 단일 책임 원칙을 지키지 않아 보수 범위가 넓어진 것으로 봐야 한다.

이런 포인트를 최소화 해야 유지보수 비용을 줄일 수 있다.

Open Closed Principle (개방 폐쇄의 원칙)

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

위에 말한 것처럼 변경이 되어야 할 경우 해당 요소에 대해서만 변경이 이루어져야하고 그 요소를 참조하는 다른 요소는 변경이 필요없도록 설계하는 것이 좋다.

또한 자신에 대해서 확장을 하는 것은 유연할 수 있어야 한다.

이를 보완하기 위해 DI, IOC를 사용한다.

Liskov Substitution Principle (리스코브 치환의 원칙)

서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다.

만약 기반 타입 (super class)이 sub1에는 필요한데 sub2에는 불필요한 기능을 가지고 있다면 다시 설계해야 한다.

만약 기반 타입으로 사용할 수 없고 서브 타입으로 사용해야 하는 경우 서브 타입에 대한 사용으로 분리해야 한다.

Interface Segregation Principle (인터페이스 분리의 원칙)

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

하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스가 낫다.

Dependency Inversion Prinsiple (의존성 역전의 원칙)

상위 모듈은 하위 모듈에 의존해서는 안된다.

상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.

추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.

따라서 구현 클래스가 아닌 인터페이스 타입으로 사용할 수 있어야 한다.

---

원칙은 그냥 어디 붙여놓고 개발하다 이따금 보게 되면 조금씩 '아 이게 이런거구나' 생각이 들게 되는 것 같다.

처음부터 '이 원칙대로 하세요' 라고 해서 받아들이는 사람도 없고 '이런 방향이 더 좋아요' 라고 말해도 본인이 납득하지 않으면 받아들여지지 않는 것 같다.

그래도 위 원칙은 계속 생각하면서 개발하는게 좋을 것 같다.