homebrew computer club

의존성 역전 원칙에서 말하는 '유연성이 극대화된 시스템'이란 소스 코드 의존성이 추상abstraction에 의존하며 구체concretion에는 의존하지 않는 시스템이다. 자바와 같은 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에 절대로 의존하지 말아야 한다. Ruby나 Python 같은 동적 타입 언어에도 이 규칙이 동일하게 적용된다. 소스 코드 의존 관계에서 구체 모듈은 참조하면 안 된다. 하지만 이들 언어의 경우 구체 모듈이 무엇인지 정의하기 다소 어렵다. 호출할 함수가 구현된 모듈이라면 참조하지 않기가 특히 어렵다. 규칙으로서 DIP는 비현실적이다. 소프트웨어 시스템이라면 구체적..

인터페이스 분리 원칙은 사진1에서 보는 다이어그램에서 그 이름이 유래했다. 사진1에 기술된 상황에서, 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을, User2는 op2만을, User3은 op3만을 사용한다. 그리고 OPS가 정적 타입언어로 작성된 클래스라고 가정하자. 이 경우 User1에서는 op2와 op3를 전혀 사용하지 않음에도 User1의 소스코드는 이 두 메서드에 의존하게 된다. 이런 의존성으로 인해 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 (사실 User1과 관련된 전혀 변경되지 않았음에도 불구하고) 컴파일한 후에 다시 배포해야 한다. 이런 문제는 그림2에서 보는 것처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다. 이번에..

1988년 바바라 리스코프는 하위 타입을 아래와 같이 정의했다. S 타입 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고 T 타입으 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다. 리스코프 치환 원칙으로 알려진 이 개념을 이해하기 위한 몇 가지 예제가 있다. 상속을 사용하도록 가이드 사진1과 같이 License라는 클래스가 있다고 가정하자. 이 클래스는 calcFee()라는 메서드를 가지며, Billing 애플리케이션에서 이 메서드를 호출한다. License에는 PersonalLicense와 BusinessLicense라는 두 가지 하위 타입이 존재한다. 이들 두 하위타입은 서로 다른 알고리즘을 이용해서 라이선스 비용을..

소프트웨어 개체artifact는 확장에 열려있어야 하고 변경에 닫혀 있어야 한다. 다시 말해 소프트웨어 개체의 행위는 확장 가능해야 하지만, 이때 개체를 변경해서는 안 된다. 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이것 때문이다. 소프트웨어 설계를 공부하기 시작한 지 얼마 안 된 사람들은 OCP를 클래스와 모듈을 설계할 때 도움되는 원칙이라고 안다. 하지만 아키텍처 컴포넌트 수준에서 OCP를 고려할 때 훨씬 중요한 의미를 가진다. 사고 실험 재무제표를 웹페이지로 보여주는 시스템이 있다고 생각하자. 웹 페이지에 표시되는 데이터는 스크롤할 수 있고, 음수는 빨간색으로 출력한다. 이제 이해관계자가 동일한 정보를 보고서 형태로 변환해서 흑백 프린터로 출력해 달라고 요청했다고 하자. 이 보고서에..

SRP: 단일 책임 원칙 단일 책임 원칙은 그 이름처럼, 모든 모듈이 단 하나의 일만 해야 한다는 의미가 아니다. 단 하나의 일만 해야 한다는 원칙은 함수에게 부여되는 원칙이다. 이 원칙은 커다란 함수를 작은 함수로 리팩터링하는 저수준에서 사용된다. 그렇다고 이 원칙이 SRP는 아니다. 역사적으로 SRP는 아래와 같이 정의되어 왔다. "단일 모듈은 변경 이유가 하나, 오직 하나뿐이어야 한다." 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 '변경의 이유'란 바로 이들 사용자와 이해관계자를 가리킨다. 사실 이 원칙은 아래와 같이 바꿔 말할 수도 있다. "하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다." 여기사 '사용자'와 '이해관계자'는 (..