단일 책임 원칙
가장 일반적이고 효과적인 소프트웨어 엔지니어링 원칙 중 하나는 밥 아저씨로 알려진 로버트 C. 마틴이 도입한 SOLID 원칙입니다. 소프트웨어 설계를 보다 이해하기 쉽고 유연하며 유지 관리할 수 있도록 하기 위한 것입니다.
SOLID는 5가지 디자인 원칙의 약자입니다.
단일 책임.
오픈 클로즈.
리스코프 대체.
인터페이스 분리.
의존성 반전.
이 기사에서는 단일 책임 원칙인 첫 번째이자 가장 쉬운 것에 대해 이야기할 것입니다.
단일 책임 원칙은 다음과 같이 말합니다.
“A class should have only one reason to change”
그러나 “단 하나의 이유”라는 말은 무엇을 의미합니까!
저는 모범이 최고의 교사라고 믿습니다. 이해를 위해 다음 코드 스니펫을 읽어보겠습니다.
class MusicPlayer{
void playMusic(){
System.out.println("Let the fun begins!");
}
void openPhoto(){
System.out.println("Really! should I open the photo now?");
}
}
보시다시피 음악을 재생하고 사진을 열 수 있는 뮤직 플레이어 클래스가 있습니다.
이 클래스가 당신이 일하는 XYZ 회사의 어떤 프로젝트에 있다고 상상해보십시오. Khaled는 XYZ의 사진 작가이며 사진 열기 기능을 사용하여 사진을 엽니다. 알리는 음악에 중독되어 음악 재생 기능을 사용하는 다른 직원입니다.
Khaled가 사진을 여는 방식을 변경하기로 결정한 경우 MusicPlayer 클래스를 열고 openPhoto 기능을 변경합니다. 마찬가지로, 완전히 다른 직원이자 다른 부서의 Ali가 그렇게 결정했다면. playMusic 기능을 사용하여 동일한 작업을 수행합니다.
우리는 학급에 변경해야 할 두 가지 다른 이유를 주었고 서로 관련이 없습니다. 하나는 음악용이고 다른 하나는 사진용입니다. 게다가 MusicPlayer 클래스와 openPhoto 함수의 관계는 무엇입니까! 나는 당신이 openPhoto가 거기에 있어서는 안 된다고 생각했다는 것을 압니다.
수업은 완전히 다른 두 직업에서 일하는 학생처럼 보입니다. 소프트웨어 엔지니어링에서 이것은 나쁜 습관입니다. 클래스가 작업을 더 많이 수행할수록 변경되기 쉬우므로 더 많은 버그와 문제가 발생합니다.
뿐만 아니라 playMusic에서 일부 코드 줄을 제거하여 openPhoto가 충돌하는 것을 확인하기로 결정했다면 상상해 보십시오. 한 장소에 있는 다른 것들이 서로 영향을 미칠 수 있습니다. 도처에 벌레, 내 친구 도처에 벌레!
따라서 책임을 분리하고 클래스에 변경 이유를 하나 지정해 보겠습니다.
class MusicPlayer{
void playMusic(){
System.out.println("Let the fun begins!");
}
}
class PhotoViewer{
void openPhoto(){
System.out.println("What about now should I open it?");
}
}
이제 언제든지 사진 기능을 변경하기로 결정했다면 음악 기능을 건드리지 않을 것이며 그 반대의 경우도 마찬가지입니다. 게다가 함수는 해당 클래스의 이름과 논리적으로 관련되어 있습니다.
실제로 많은 기능이 존재하기 때문에 클래스에 변경 이유를 하나만 제공하는 것은 매우 어렵지만 가능한 한 관련 기능을 유지하는 것입니다. 이것은 일반적으로 소프트웨어 엔지니어링에서 응집력으로 알려져 있습니다. 응집력이 높은 클래스는 좋은 디자인을 나타냅니다.
함수에도 단일 책임 원칙을 적용할 수 있습니다. 함수는 더도 덜도 말고 하나의 특정 작업을 수행해야 합니다.
함수를 작성할 때 항상 자신에게 물어보십시오. 함수는 무엇을 합니까? 만약 당신이 그것이 무언가 "그리고"무언가를 한다고 말한다면. 그리고 이것은 당신이 잘못하고 있다는 것을 의미합니다.
이것이 지금 우리 여행의 끝입니다.
곧 우리는 개방형 원칙으로 또 다른 여정을 시작할 것입니다. 그냥 기다려!
Reference
이 문제에 관하여(단일 책임 원칙), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/amrsaeedhosny/single-responsibility-principle-3ajo텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)