SOLID 설계 원칙에 이미 익숙한 사용자에게는 이것이 그다지 새로운 일이 아닐 것입니다. 그러나 초보자를 위해

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

규칙보다는 모범 사례에 가깝습니다.

단일 책임

SOLID의 S.

그것은 말한다

A class should have one, and only one reason to change.

목표는 행동이나 관심사를 분리하는 것입니다. 모든 것은 각자의 자리가 있고 그 자리에 있어야 합니다.

원래

더 작은 코드 모듈 만들기(클래스/함수 등)

모듈은 특정 작업만 수행하며 이에 대해서만 책임을 집니다.

그것은 그것이 하는 일에 대해 정확하게 명명되었습니다.

책임과 행동이 다른 Large Generic 클래스와는 대조적입니다.

이 패턴은 역할별 인터페이스를 만드는 데 중점을 둔 다른 SOLID 원칙에서 볼 수 있습니다.

간단한 사용 사례

임의의 사용자 데이터를 일부 데이터베이스에 저장한다고 가정해 보겠습니다. 이것은 우리가 일반적으로 함수(의사 코드-ish) 내에서 수행하는 작업입니다.

function createUser(userData){
    // 1. validate user data for email and password keys

    // 2. check if the email is already registered

    // 3. save the user to DB 

    // 4. return saved user as a response
}

SINGLE RESPONSIBILITY 접근 방식을 사용하여 특정 논리를 처리하고 해당 논리만 담당하는 전용 기능을 만들 것입니다.

function validateUser(user){
    // will validate userObject for email and password keys
}

function isEmailRegistered(email){
    // will check if the email is already taken 
}

function saveUserData(user){
    // will save user data to db
}

function createUser(userData){
    validateUser(userData)

    if(isEmailTaken(userData.email)){
      // throw some error here
    }

    var user = saveUserData(userData)

    return user
}

이것은 간단한 예이지만 여러 유효성 검사와 복잡한 논리를 처리할 때 이러한 유형의 접근 방식은 정말 편리합니다.

그것을 사용하는 이유

이것들을 고려하십시오

따라하기 쉽고 이해하기 쉽습니다

디버깅이 쉬워졌습니다.

제거 및 리팩토링이 이전보다 훨씬 간단합니다.

두려움 없이 더 큰 변화를 만들 수 있습니다.

확장 및 유지 관리가 가능합니다.

또한 변경해야 하는/해야 하는/필요한/강요된 시간이 있고 단일 책임을 따랐을 때 훨씬 빠르고 쉬울 것입니다.

무언가를 깨거나 버그가 있으면 어떻게 합니까? 글쎄요, 이 원칙에 따라 쉽게 추적할 수 있으며, 무언가를 깨뜨리면 전체 시스템이 아니라 그 하나만 깨는 것입니다.

이 규칙은 다음과 같은 다른 SOLID 원칙을 구현하는 데 많은 도움이 됩니다.

팁

프로젝트에 대한 테스트를 작성하는 사람이라면 이 규칙을 좋아할 것입니다. 예측 가능한 동작과 제어를 제공합니다.


여기 있습니다. 간단하고 쉬운 방법으로 설명했기를 바랍니다. 프로젝트에서 SOLID 원칙을 사용합니까? 아래에 의견을 보내주십시오.

무엇 향후 계획

Laern이 2분 안에 원리에 대해 설명합니다.