안녕하세요. 휴먼스케이프 개발자 Jake입니다.
좋은 소프트웨어 아키텍처란 무엇일까요?
구축에 필요한 재료와 최선의 방법으로 앞으로 만들어질 결과물을 예측하고 조화롭게 설계하는 것 아닐까요?
오늘은 객체지향설계원칙인 SOLID 의 5가지 원칙중 S와 O에 해당하는 SRP: 단일 책임 원칙과 OCP: 개방-폐쇄 원칙에 대해서 알아보도록 하겠습니다.
SRP: 단일 책임 원칙
Single Responsibility Principle
단일 책임 원칙: 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이여야 한다.
조금 더 쉽게 말하면 하나의 모듈은 하나의 이해관계자에 대해서만 책임을 져야 한다라고 할 수 있겠습니다. 단일 책임이 원칙 필요한 이유를 클래스 다이어 그램을 이용하여 예시를 들어보겠습니다.
예시: 세가지 메서드가 서로 다른 이해관계자를 책임지는 경우
Employee Class
위의 그림에서 calculatePay와 reportHours가 업무시간을 계산하는 로직을 regularHours라 하고 이를 공유한다고 가정해보겠습니다. calculatePay 이해관계자가 로직을 변경을 원해 rugularHours를 변경했다면 reportHours는 변경에 대해서 모른체 엉터리동작을 수행할 수 있고, reportHours에서 변경을해도 같은 문제가 일어날 수 있습니다.
해결: 데이터와 메서드의 분리
이해관계자의 요구사항을 충족시키기 위한 해결책은 메서드를 각각의 클래스로 분리하는 것입니다. 위의 그림에서 Employee Data를 세가지 클래스로 분리하게 되면 각각의 클래스를 인스턴스화하고 추적해야 한다는게 단점이므로 이럴때에는 Facade 패턴을 사용하여 해결합니다. 이렇게 하면 Employee Facade 클래스가 PayCalculator, HourReporter, EmploeeServer 클래스 객체를 생성하고, 메서드 요청시 해당 메서드를 가진 객체로 위임하는 역할을 수행합니다.
OCP: 개방-폐쇄 원칙
개방-폐쇄 원칙: 소프트웨어 개체는 확장에는 열려 있어야하고 변경에는 닫혀 있어야 한다.
요구사항이나 추가사항이 있더라도 기존 소프트웨어 개체는 수정이 일어나지 않아야하며 기존구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 말입니다. 예시를 한번 살펴보도록 하겠습니다.
예시: 기능의 확장으로 클래스의 변경이 일어난다.
핸드폰 사용자인식을 생각해 볼 수 있습니다. 이 클래스는 기본적으로 번호를 눌러 사용자를 인식한다고하고, 요청사항으로 지문인식, 홍체인식, 얼굴인식을 할 수 있어야 한다고 하면 recognize 메서드를 수정할 수 밖에 없고 이는 OCP원칙을 위배했다고 할 수 있습니다.
해결: 인터페이스를 만들어서 메소드를 재정의한다.
MobileRecognize에서 recognize interface를 멤버변수로 만들고, MobileRecognize객체 생성 후 setRecognize에 recognize interface를 구현한 클래스 인스턴스를 넣어주고 recognize를 실행한다. 이렇게하면 인식에 있어서 기존의 소스들을 변경하지않고 확장에는 열려있는 구현을 할 수 있다.
오늘 준비한 내용은 여기까지 입니다. 다음에 더 알찬내용으로 다시 찾아 뵙도록 하겠습니다. 감사합니다.
Get to know us better! Join our official channels below.
Telegram(EN) : t.me/Humanscape KakaoTalk(KR) : open.kakao.com/o/gqbUQEM Website : humanscape.io Medium : medium.com/humanscape-ico Facebook : www.facebook.com/humanscape Twitter : twitter.com/Humanscape_io Reddit : https://www.reddit.com/r/Humanscape_official Bitcointalk announcement : https://bit.ly/2rVsP4T Email : support@humanscape.io
가입하기
