소프트웨어 개발의 원칙
SOLID
대상 프로그래밍 안내
다음 5가지 원칙의 이니셜을 따서 SOLID의 원칙이라고 한다
SRP 단일 책임 원칙
학급은 단일한 책임을 져야 한다
예를 들어 클래스가 A와 B의 대상을 담당할 때 A의 행위를 수정할 때도 B에 영향을 줄 수 있다.
A
-> クラス
B
A -> Aクラス
B -> Bクラス
OCP 공개 관문의 원칙
클래스는 개방식이고 변경은 닫기식이어야 한다
클래스에 기능을 추가할 때 코드를 변경하는 것이 아니라 추가적인 디자인을 해야 한다.
예를 들어 ABC라는 3가지 기능을 가진 클래스 ABC의 경우 D라는 기능을 추가하려면 클래스 ABC에 D라는 기능을 직접 탑재하는 형태가 된다.
이렇게 되면 ABC 기능을 사용하는 다른 학급에도 영향을 미칠 수 있다.
クラスABC + D = クラスABCD
クラスABCD = クラスA + クラスB + クラスC + クラスD
LSP 목록의 교체 지침
자류는 부모류와 같은 동작을 할 수 있어야 한다
반에서 다른 반을 만들 때 반은 부모가 되고 새로 만든 반은 자반이 된다.이게 상속이야.
하위 클래스에 상위 클래스와 같은 기능이 없으면 하위 클래스를 상위 클래스로 대체하는 경우 큰 변화가 발생합니다.
예를 들어 A기능이 있는 부류, B기능이 있는 부류가 존재하는 경우 B를 부류로 설정할 때 A기능을 다시 실시해야 한다.
A, B -> B + A
A, A' -> A'
ISP 인터페이스 분리 지침
클라이언트가 사용하지 않는 방법에 대한 의존을 강요해서는 안 된다
예를 들어 클래스에서 B 기능을 실현할 때 A와 B 기능을 정의한 인터페이스를 계승하면 A도 반드시 실현해야 한다.
IAB -> B + A
IA, IB -> A, B
DIP 의존성 역전의 법칙
상급 모듈은 하급 모듈에 의존할 수 없다.각자 추상에 의존해야 한다
예를 들어 A가 B에 의존하는 경우 B가 변경될 때 A도 수정해야 한다
A -> B
A -> IB <- B
KISS
Keep It Short And Simple
간단 명료하다
어쨌든 코드는 간단해야 돼.
인코딩이 복잡할수록 유지 보수가 어려워지기 때문에 어떻게 간단하게 유지하는가가 매우 중요하다.
어려운 것은 간단하지만, 간단하게 쓰는 것은 매우 어렵다.
YAGNI
You Aren't Going to Need It
그건 필요 없어요.
코드는 나중에 설치해야 합니다.
일단... 실제 설치한 코드가 활용된 경우는 얼마나 될까.(내 경험에 의하면 십중팔구는 필요 없다)
차라리 그 코드의 존재로 기술적인 부채가 되는 경우도 적지 않을 것 같다.
DRY
Don't Repeat Yourself
되풀이하지 마라
같은 코드를 반복해서 쓰지 않는다.
중복된 코드는 개선할 때 중복된 모든 부분을 수정해야 한다
따라서 가능한 한 처리를 함수나 모듈에 집합한다.
그러나 과도한 DRY는 밀접하게 결합하는 반면 안 좋은 경우도 있기 때문에 무엇이든 DRY로 만들 수 있는 것은 아니다.
PIE
Program Intently and Expressivery
프로그래밍
코드는 명확하게 쓴 의도와 동시에 쓴 것이다.
코드를 쓰는 것보다 더 많이 읽는다.쓰기 쉬울 때보다 읽기 쉽다는 의식을 가져야 한다는 것이다.
참고 자료
Reference
이 문제에 관하여(소프트웨어 개발의 원칙), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/cohky/articles/development-principles텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
