KDT Unity 2주차~4주차 - S, O, L, I, D 원칙이란?

2023-11-29 TIL

알고리즘 문제

오늘의 알고리즘 문제 : 내적

길이가 같은 두 1차원 정수 배열 a, b가 매개변수로 주어집니다. a와 b의 내적을 return 하도록 solution 함수를 완성해주세요.

using System;

public class Solution {
    public int solution(int[] a, int[] b) {
        int answer = 1234567890;
        return answer;
    }
}

해결

using System;

public class Solution {
    public int solution(int[] a, int[] b) {
        int answer=0;
        for(int i = 0; i < a.Length; i++)
        {
            answer += (a[i]*b[i]);
        }
        return answer;
    }
}

for(int i = 0; i < a.Length; i++){answer += (a[i]*b[i]);}을 사용하여 해당 배열의 값 을 다 더해 answer값에 넣어주고 리턴해줍니다.

S, O, L, I, D 원칙

S - 단일 책임의 원칙 Single Responsibility Principle

작성된 클래스는 하나의 기능만 가지며 모든 서비스는 그 하나의 책임을 수행해야 한다는 원칙입니다. 이는 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나를 의미합니다.
뿐만 아니라 책임을 적절히 분배함으로써 코드의 가독성 향상, 유지보수를 더욱 편리하며 용이하게 다룰수 있습니다.

O - 개방 폐쇄 원칙 Open-Closed Principle

소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원리입니다. 이것은 변경 최소화하고 확장을 위한 가능성은 최대한 확대함을 의미합니다.
요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며, 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 뜻입니다.
개방 폐쇄 원칙을 가능하게 하는 중요 메커니즘은 추상화와 다형성이라고 할수 있습니다.
OCP는 객체지향의 장점을 극대화하는 아주 중요한 원리라 할 수 있습니다.

L - 리스코프 치환 원칙 Liskov Substitution Principle

“서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다.”라고 할 수 있습니다.
서브 타입은 기반 타입이 정한 기능을 지켜야 합니다. 상속은 구현상속(extends 관계)이든 인터페이스 상속(implements 관계)이든 궁극적으로는 다형성을 통한 확장성 획득을 목표로 합니다.
다형성과 확장성을 극대화 하려면 하위 클래스를 사용하는 것보다는 상위의 클래스(인터페이스)를 사용하는 것이 더 좋습니다.
일반적으로 선언은 기반 클래스로 생성은 구체 클래스로 대입하는 방법을 사용합니다

I - 인터페이스 분리 원칙 Interface segregation principle

어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 합니다. ISP를 ‘하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다’라고 정의할 수 도 있습니다. SRP가 클래스의 단일책임을 강조한다면 ISP는 인터페이스의 단일책임을 강조합니다.
하지만 ISP는 어떤 클래스 혹은 인터페이스가 여러 책임 혹은 역할을 갖는 것을 인정합니다. 이러한 경우 ISP가 사용되는데 SRP가 클래스 분리를 통해 변화에의 적응성을 획득하는 반면, ISP에서는 인터페이스 분리를 통해 같은 목표에 도달 합니다.

D - 의존 역전 원칙 Dependency Inversion Principle

의존 관계의 역전 Dependency Inversion 이란 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 의미의역전입니다.
실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써 관계를 최대한 느슨하게 만드는 원칙입니다.
DIP는 복잡한 컴포넌트간의 커뮤니케이션 관계를 단순화하기 위한 원칙입니다.

오늘의 정리

어제에 이어서 솔리드 원칙을 좀더 구체적으로 정리해봤다.

하지만 역시 아직까지는 이해가 좀 많이 어려운거 같다.

나중에 시간이 나면 하나씩 조금더 확실하게 구체적으로 정리를 해보는 시간이 필요할거 같다.

시간이 된다면 꼭 다시 재정리를 해서 올려보도록 하겠다.