블로그명..?

REP(Reuse/Release Equivalence Principle) - 재서용/릴리스 등가 원칙 CCP(Common Closure Principle) - 공통 폐쇄 원칙 CRP(Common Reuse Principle) - 공통 재사용 원칙 REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 소프트웨어 컴포넌트가 릴리스 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부여되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것이다. 릴리스 번호를 통해 재사용 컴포넌트들이 서로 호환되는지 알 수 있다. 개발자들은 릴리스 변경사항을 살펴보고 이를 적용할지 결정할 수 있다. 이 원칙은 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 ..

SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다. 큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 예시) 자바 - jar 루비 - gem 닷넷 - DLL 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 또는 여러 컴포넌트를 서로 묶어서 .war 파일과 같은 단일 아카이브로 만들 수도 있다. 또는 컴포넌트 각각을 .jar나 .dll 같이 동적으로 로드할 수 있는 플러그인이나 .exe 파일로 만들어서 독립적으로 배포할 수도 있다. 잘 설계된 컴포넌트는 반드시 독립적으로 배포 가능한, 따라서 ..

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

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

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

개방-폐쇄 원칙(OCP)라는 용어는 1988년에 버트란트 마이어가 만들었는데, 다음과 같다. 소프트웨어 개체는 확장에는 열려 있어야하고, 변경에는 닫혀 있어야 한다. 이는 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 개체를 변경해서는 안 된다는 뜻이다. 만약 요구사항을 확장하는 데 소프트웨어를 많이 수정해야 한다면, 그 소프트웨어 시스템을 설계한 아키텍트는 엄청난 실패를 한 것이다. 사고 실험 재무제표를 웹 페이지로 보여주는 시스템이 있다고 생각해보자. 웹 페이지에 표시되는 데이터는 스크롤할 수 있으며, 음수는 빨간색으로 출력한다. 이것을 이해관계자가 보고서 형태로 변환해서 흑백 프린터로 출력해 달라고 요청했다고 해보자. 바뀌는 부분 데이터 : 재무 데이터 -> 보고서용 재무 데이터 출력 방..

함수형 프로그래밍이라는 개념은 프로그래밍그 자체보다 앞서 등장했다. 이 패러다임에서 핵심이 되는 기반은 람다 계산법으로 알론조 처치가 1930년대에 발명했다. 아래는 25까지의 정수의 제곱을 출력하는 자바 언어의 예시이다. public class Squint { public static void main(String args[]) { for (int i=0; i ex) range 함수 호출 : (range) 표현식 (fn [x] (* x x)) 는 익명 함수로, 곱셈 함수를 호출하면서 입력 인자를 두 번 전달한다. (입력의 제곱을 계산한다.) 전체 코드를 다시 해석해보자. range 함수는 0부터 시작해서 끝이 없는 정수 리스트를 반환한다. 반환된 정수 리스트는 map 함수로 전달되고, 각 정수에 대해 ..

OO란 무엇인가? 데이터와 함수의 조합? 이는 터무니없는 말이다. o.f() f(o)와 다르다는 의미를 내포하기 때문이다. 실제 세계를 모델링하는 새로운 방법? 이는 얼버무리는 수준에 지나지 않는다. 의도가 불분명하며, 그 정의가 너무 모호하다. 캡슐화, 상속, 다형성? OO(Obejct-Oreiented)가 이 세 가지 개념을 적절하게 조합한 것이거나, 또는 최소한 세 가지 요소를 반드시 지원해야 한다고 말한다. 이 세 가지 개념에 대해 살펴보자. 캡슐화? OO를 정의하는 요소 중 하나로 캡슐화를 언급하는 이유는 데이터와 함수를 쉽교 효율적으로 캡슐화하는 방법을 OO언어가 제공하기 때문이다. 데이터와 함수가 응집력 있게 구정된 집단을 서로 구분 짓는 선을 그을 수 있다. 구분선 바깥에서 데이터는 은닉되..