'SOLID'라는 약어는 모든 좋은 객체 지향 프로그램이 따라야 하는 규칙과 원칙의 모음입니다. 이 게시물은 단일 책임 원칙과 C#의 좋은 구현과 나쁜 구현의 예에 중점을 둡니다. 다른 원칙은 이후 블로그 게시물에서 다룰 것입니다.


단일 책임 원칙은 클래스가 한 가지만 수행해야 한다고 명시되어 있습니다. 클래스가 너무 많은 작업을 수행하면 코드를 유지 관리하기가 더 어려워집니다. 다음 클래스는 단일 책임 원칙을 따르지 않습니다.

class AmericanoMaker
    {
        void grindCoffeeBeans()
        {
            Console.WriteLine("Grinding the coffee beans...");
        }
        public void makeDrink()
        {
            grindCoffeeBeans();
            Console.WriteLine("Done! your coffee is ready :)");
        }
    }

그림 1: 사용자를 위해 맛있는 아메리카노를 만드는 것을 시뮬레이션하는 클래스.

그림 1에 표시된 클래스는 너무 많은 작업을 수행합니다. 아메리카노를 만드는 역할만 하는 것은 아닙니다. 또한 커피 원두를 갈아야 합니다. 이는 궁극적으로 코드를 유지 관리하기 어렵게 만듭니다. 이 예제는 응용 프로그램에 다른 클래스를 도입한 후에 더 이해가 됩니다.

class CappuccinoMaker
    {
        void grindCoffeeBeans()
        {
            Console.WriteLine("Grinding the Coffee Beans...");
        }
        void steamMilk()
        {
            Console.WriteLine("Steaming the milk...");
        }
        public void makeDrink()
        {
            grindCoffeeBeans();
            steamMilk();
            Console.WriteLine("Done! your coffee is ready :)");
        }
    }

그림 2: 사용자를 위한 맛있는 카푸치노 만들기를 시뮬레이션하는 클래스

그림 2는 너무 많은 일을 하는 또 다른 클래스를 보여줍니다. 수업은 원두를 갈아서 우유를 데우고 카푸치노를 만듭니다.

이 새 클래스를 도입한 후 끔찍한 일이 발생했음을 여기에서 눈치채셨을 것입니다! 두 클래스 모두 이제 GrindCoffeeBeans 메서드를 갖습니다. 중복 코드는 한 방법의 변경이 다른 방법에 수행되어야 하므로 소프트웨어 개발에 좋지 않습니다. 이것이 효과적으로 한 가지 일을 하는 클래스가 유지 관리하기 쉬운 이유입니다. 클래스에 기능이 하나만 있으면 코드를 복제하기가 훨씬 더 어렵습니다. 따라서 이전 예제의 단점을 살펴보고 더 나은 커피 시뮬레이터 구현을 살펴보겠습니다.

class MilkSteamer
    {
        public void steamMilk()
        {
            Console.WriteLine("Steaming the milk...");
        }
    }

    class CoffeeGrinder
    {
        public void grindCoffeeBeans()
        {
            Console.WriteLine("Grinding coffee beans...");
        }
    }

    class CapuccinoMaker
    {
        private CoffeeGrinder coffeeGrinder;
        private MilkSteamer milkSteamer;
        public void makeDrink()
        {
            coffeeGrinder.grindCoffeeBeans();
            milkSteamer.steamMilk();
            Console.WriteLine("Done! your coffee is ready :)");
        }
    }

    class AmericanoMaker
    {
        private CoffeeGrinder coffeeGrinder;
        public void makeDrink()
        {
            coffeeGrinder.grindCoffeeBeans();
            Console.WriteLine("Done! your coffee is ready :)");
        }
    }

그림 3: 맛있는 커피를 만드는 아름답게 디자인된 클래스 시스템.

새로운 클래스 디자인은 우유 찌는 기능과 커피 분쇄 기능을 자체 클래스로 분리합니다. 이 간단한 변경으로 앞에서 설명한 중복 코드 재해가 수정되었습니다. 이것은 AmericanoMaker 및 CappuccinoMaker 클래스가 이제 CoffeeGrinder 클래스에서 동일한 방법을 사용하여 커피를 분쇄하기 때문입니다. 따라서 커피 원두 분쇄 과정에 대한 변경은 CoffeeGrinder 클래스에서만 수행하면 됩니다.

As a general rule if you find yourself having methods that do the same thing in different parts of your application, the design of your app could probably be improved. Well designed classes do not have repeated code.

결론

이 블로그 게시물에서는 몇 가지 예제 클래스를 사용하여 단일 책임 원칙을 따를 때의 이점에 대해 설명했습니다. 우리는 한 가지 일을 하는 클래스를 작성하는 것이 더 유지보수 가능한 코드베이스로 이어진다는 것을 배웠습니다.

이 블로그 게시물은 SOLID 설계 원칙에 초점을 맞춘 일련의 게시물 중 첫 번째 게시물이므로 뛰어난 객체 지향 응용 프로그램 설계에 대한 추가 팁을 계속 지켜봐 주시기 바랍니다!

읽어주셔서 대단히 감사합니다. 주저하지 말고 아래에 질문을 하시면 제가 답변해 드리겠습니다! 😄

추가 리소스

다음은 좋은 객체 지향 프로그램을 설계하는 데 매우 유용한 기타 리소스 목록입니다.

Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D