대상을 대상으로 프로그래밍하는 견고한 원칙을 배우다

오브젝트 프로그래밍(OOP)은 데이터와 행동을 오브젝트라고 불리는 모델에 봉인하는 프로그래밍 스타일이다.이런 방식을 통해 관련 코드는 한데 묶여 다른 코드와 분리되고 다시 사용할 수 있는 블록을 제공한다. 이 블록들은 수중의 문제를 합리화하는 데 사용할 수 있다.
OOP는 가장 흔히 볼 수 있는 프로그래밍 형식 중 하나일 수 있다. C#, Java, JavaScript를 포함한 많은 유행하는 프로그래밍 언어는 모두 이 점을 바탕으로 구축된 것이다.
많은 언어에서 대상의 청사진을 클래스라고 부른다.이 클래스는 속성과 함수 (일반적으로 방법이라고 부른다) 를 포함한 대상의 모든 정의를 포함한다.
실제 대상을 만들기 위해서, 우리는 클래스의 실례를 만들었는데, 그 중의 모든 속성 정의는 실제 값을 부여했다.중요한 것은 우리가 같은 종류의 여러 개의 실례를 동시에 존재할 수 있고 각 실례는 서로 다른 값을 가지고 있다는 것이다.
예를 들어 우리는 간단한 Person 클래스를 만들 수 있습니다. 이 클래스는name 속성과speak 방법을 가지고 있습니다.

public class Person
{
    public Person(string name)
    {
        Name = name;
    }

    public int Id { get; set; }

    public string Name { get; set; }

    public void Speak()
    {
        Console.WriteLine($"My name is {Name}");
    }
}

이것은 청사진이다.현재 우리는 이 종류의 두 개의 독립된 실례를 만들 수 있다.speak 방법은 서로 다른 출력을 제공할 것이다. 왜냐하면 모든 실제 대상은 서로 다른name 속성 값을 실례화하기 때문이다.

var bernard = new Person("Bernard");
var sally = new Person("Sally");

bernard.Speak(); // outputs "My name is Bernard"
sally.Speak(); // outputs "My name is Sally"

이것은 모두 매우 간단한 예이지만, 이러한 대상의 청사진을 만들고 실제 대상을 만드는 단독 실례의 장점을 볼 수 있기를 바랍니다.
그러나 조심하지 않으면 대상을 오용하여 읽기 어렵거나 불안정한 코드가 생기기 쉽다.예를 들어, 당신은 최종적으로 "God"클래스를 얻을 수 있습니다. 이 클래스는 같은 대상에 관련되지 않은 많은 행동을 가득 채울 수 있습니다.
잘 작성되고 유지보수가 가능하며 안정적인 코드를 돕기 위해 튼튼한 원칙을 소개했다.

S-단일 책임 원칙

O-켜기/끄기 원리

L-Liskov 교체 원리

I-인터페이스 분리 원칙

D-의존 역치 원리

S-단일 책임 원칙

이곳의 제목은 말하지 않아도 안다.한 반에는 마땅히 하나의 직책이 있어야 한다.이것은 하느님 클래스의 상황을 피하기 위해서이다. 이런 상황에서 한 클래스는 모든 일을 하고 코드를 더욱 작고 합리적인 블록으로 분할하는 데 도움을 준다.
단일 책임 원칙은 이해하기 쉽지만 실천에서 어떤 사물이 언제 어떤 종류에 속하고 언제 다른 종류로 옮겨야 하는지를 발견하는 것은 결코 그렇게 간단하지 않다.이런 판단을 하는 것은 주로 경험 문제이다. 시간의 추이에 따라 너는 더욱 잘 할 수 있을 것이다.
만약 우리가 Person 클래스로 돌아간다면, 우리는 모든 사람을 데이터베이스에 저장하기로 결정할 것이다.따라서 Person 클래스에서 하나의 방법을 만드는 것은 현명한 것 같다.

public class Person
{
    // ... other properties and methods

    public void SaveToDatabase()
    {
        // logic to save person
    }
}

그러나 여기서 문제는 어떻게 인원을 데이터베이스에 저장하는지의 세부 사항은 별도의 직책이기 때문에 직책은 다른 종류로 옮겨야 한다는 것이다.
따라서 우리는 SavePerson 방법으로 데이터베이스 클래스를 만들고 Person의 실례를 이 클래스에 전달할 수 있다.이렇게 하면 Person 클래스는 인원의 상세한 정보만 처리하고 데이터베이스 클래스는 저장자의 상세한 정보를 처리한다.

public class Database 
{
    public void SavePerson(Person person)
    {
        // logic to save person
    }
}

O-켜기/끄기 원칙

열기/닫기 원칙에 따라 객체는 확장할 수 있지만 수정할 수 있도록 닫아야 합니다.이것은 당신이 이러한 방식으로 대상을 설계해야 한다는 것을 의미한다. 즉, 그것들은 쉽게 확장할 수 있고, 직접 수정할 필요가 없다는 것이다.
예를 들어 우리는 두 개의 새로운 클래스, 즉 Employee와 Manager를 정의할 수 있다. 이 클래스는 Person 클래스에서 파생된 것이고 Salary Calculator 클래스에서 파생된 것이다.

public class Employee : Person
{
    // employee methods and properties
}

public class Manager : Person
{
    // manager methods and properties
}

public class SalaryCalculator
{
    public decimal CalculateSalary(Person person)
    {
        if (person is Employee)
        {
            return 100 * 365;
        }
        else if (person is Manager)
        {
            return 200 * 365;
        }
    }
}

이 예에서 Salary Calculator 클래스는 열기/닫기 원칙을 위반합니다. 만약에 우리가 디렉터 클래스를 추가해서 프로그램을 확장한다면, 우리는 이 점을 설명하기 위해 Calculate Salary 방법을 수정해야 하기 때문입니다.
이 문제를 해결하기 위해 우리는 모든 Person 유형에 DailyRate 속성을 추가할 수 있다.이렇게 하면 Salary Calculator를 수정하지 않고 임의의 인원 유형을 추가할 수 있습니다.

public class Person
{
    public virtual decimal DailyRate => 0;
}

public class Employee : Person
{
    public override decimal DailyRate => 100;
}

public class Manager : Person
{
    public override decimal DailyRate => 200;
}

public class Director : Person
{
    public override decimal DailyRate => 300;
}

public class SalaryCalculator
{
    public decimal CalculateSalary(Person person)
    {
        return person.DailyRate * 365;
    }
}

L-Liskov 교체 원리

Liskov 교체 원칙에 따르면 모든 하위 클래스는 기본 클래스를 교체할 수 있고 프로그램은 예상대로 실행될 것입니다.
개/폐 원리의 예도 Liskov 교체 원리의 좋은 예이다.
Salary Calculator 클래스에서 이 방법은 기본 클래스인 Person을 받아들이지만, 실행할 때 우리는 그 어떠한 하위 클래스도 전달할 수 있다.Person과sub류에서 각각virtual과override 키워드를 사용했기 때문에Calculatesaly 방법에서 DailrRate의 값은sub류의 값이 될 것이다. 즉, 우리가 Calculatesaly 방법의 기본 클래스로 하위 클래스를 바꾸어도 이 방법은 정상적으로 작동할 수 있다.
Liskov 대체 원칙 위반의 예로서 클래스를 다음과 같이 재정의할 수 있습니다.

public class Person 
{
    public decimal DailyRate => 0;
}

public class Employee
{
    public new() decimal DailyRate => 100;
}

이 정의에서 우리는 Liskov 교체 원칙을 위반했다. 왜냐하면 데일리 레이트는 Salary Calculator에서 항상 하위 클래스의 값이 아니라 0으로 계산되기 때문이다.

I-인터페이스 분리 원칙

인터페이스 격리 원칙은 클라이언트가 사용하지 않는 인터페이스의 속성과 방법을 강제해서는 안 된다고 규정하고 있다.따라서 몇 개의 크고 통용되는 인터페이스가 아니라 많은 작고 특정한 인터페이스를 정의하는 것이 가장 좋다.
예를 들어, 데이터베이스에서 Person 클래스를 위해 CRUD 작업을 수행하고 이를 실현하기 위해 IRepository 인터페이스를 정의할 수 있습니다.

public interface IRepository
{
    bool Create(Person person);
    Person Get(int id);
    IEnumerable<Person> GetAll();
    bool Update(Person person);
    bool Delete(int id);
}

public class Repository : IRepository
{
    public bool Create(Person person)
    {
        // create logic
    }

    public Person Get(int id)
    {
        // get logic
    }

    // etc
}

만약 우리가 항상 완전한 CRUD 기능이 필요하다는 것을 안다면, 이것은 매우 좋다.그러나 실제로 우리가 메모리 라이브러리만 읽기만 한다면 어떨까?설령 우리가 그것들을 필요로 하지 않는다 하더라도, 우리는 완전한 때 쌓인 조작을 실행해야 한다.
반대로 우리는 여러 개의 인터페이스를 정의하여 우리가 필요로 하는 인터페이스만 실현할 수 있다.

public interface ICreatableRepository
{
    bool Create(Person person);
}

public interface IGettableRepository
{
    Person Get(int id);
    Person GetAll();
}

public interface IUpdateableRepository
{
    bool Update(Person person);
}

public interface IDeletableRepository
{
    bool Delete(int id);
}

그런 다음 읽기 전용 저장소나 전체 CRUD 저장소를 만들 수 있습니다.

public class ReadonlyRepository : IGettableRepository
{
    public Person Get(int id)
    {
        // get logic
    }

    public IEnumerable<Person> GetAll()
    {
        // get all logic
    }
}

public class CrudRepository : ICreateableRepository, IGettableRepository, IUpdateableRepository, IDeleteableRepository
{
    public bool Create(Person person)
    {
        // create logic
    }

    public Person Get(int id)
    {
        // get logic
    }

    // etc
}

역치 원리에 의존하다

의존 역치 원칙은 클래스는 다른 클래스에 의존해서는 안 되고 이런 클래스가 실현하는 인터페이스에 의존해야 한다고 지적했다.이것은 의존 관계의 방향을 반전시키는 효과가 있다.
예를 들어 클래스로만 구성된 전통적인 3층 응용 프로그램에는 PersonPresenter 클래스가 하나 있을 수 있습니다. 이 클래스는 PersonLogic 클래스에 의존하고 이 클래스는 PersonRepository 클래스에 의존합니다.예를 들면

PersonPresenter --> PersonLogic --> PersonRepository

문제는 고급 표시와 저급 구현의 디테일을 밀접하게 결합시킨다는 점이다.가장 좋은 것은 느슨한 결합 코드를 사용하는 것이다. 이것은 인터페이스를 통해 실현할 수 있다.인터페이스 사용에 대한 자세한 내용은 이전 블로그 글을 참조하십시오.

코드에서 인터페이스를 사용한 세 가지 이유

샘 월폴・ 2020년 4월 13일・ 5분 읽기

#interfaces #solid #csharp #javascript

의존 관계를 반전시키기 위해 우리는 모든 저급 클래스의 인터페이스를 만들고 이 클래스를 실현할 수 있다.

PersonPresenter --> IPersonLogic <-- PersonLogic --> IPersonRepository <-- PersonRepository

결론

따라서 대상을 대상으로 프로그래밍하는 튼튼한 원칙은 5가지다.만약 당신이 그것이 유용하다고 생각한다면, 이 글을 좋아하고 공유하세요.만약 네가 원한다면 언제든지 나를 따라와라, 너도 할 수 있다buy me a coffee!😊