Design (27) 썸네일형 리스트형 [Clean Architecture] 컴포넌트 사이의 관계와 원칙(3) : SAP SAP(안정된 추상화 원칙)이란? 컴포넌트는 안정된 정도만큼만 추상화되어야 한다. 고수준 정책은 어디에 위치시켜야하는가? 고수준 아키텍처나 정책 결정과 관련된 소프트웨어는 자주 변경해서는 절대로 안 되는 소프트웨어 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I=0)에 위치해야 한다. 하지만 안정된 컴포넌트에 위치 시킨다면 변경이 어려운 단점이 있음. (유연성이 떨어짐) 추상 클래스를 통해 컴포넌트가 최고로 안정된 상태(I=0)이면서도 동시에 유연하게 만들 수 있다. 안정된 추상화 원칙 (Stable Abstractions Principle) 안정성과 추상화 정도 사이의 관계를 정의. 안정된 컴포넌트는 추상 컴포넌트여야 함(인터페이스와 추상 클래스로 구성). 이를 통해 안정성이 컴포넌트를.. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(2) : SDP SDP(안정된 의존성 원칙)란? 안정성의 방향으로(더 안정된 쪽에) 의존하라 즉, 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들어야한다. 그렇다면 안전성이란? 사전적으로는 ‘쉽게 움직이지 않는’으로 정의. 안정성은 변경을 위해 필요한 작업량과 관련된다. 안정성이 높으면 상당한 작업량이 필요함. (탁자를 뒤집는 것과 옆으로 세워진 동전을 넘어뜨리는 것을 생각해보자) 소프트웨어 관점에서의 안정성 컴포넌트 변경이 어려운 요인에는 크기, 복잡도, 간결함 등이 있음. 컴포넌트 변경이 어려운 가장 확실한 방법은 “수많은 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.” 안정적인 컴포넌트 - X는 안정된 컴포넌트. - 세 컴포넌트가 x에 의존함에 따라 X컴포넌트는 변경하지 말아야할 이.. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(1) : ADP ADP (의존성 비순환 원칙) 란? 컴포넌트 의존성 그래프에 순환이 있어서는 안 된다. ADP를 이야기하기 전에 숙취 증후군에 대해서 알아보자. 숙취 증후군은 당신이 하루종일 작업하여 무언가를 작동하게 만들어 놓았지만, 그 기능이 의존하는 무언가를 다른 팀이 수정하여, 다음 날 출근하면 그 기능이 전혀 돌아가지 않는 것을 이야기한다. 숙취 증후군 해결책으로 두 가지 방법이 발전되어 왔는데 하나씩 알아보도록 하자. 1. 주단위 빌드 모든 개발자는 일주일의 첫 4일 동안은 각자 개발을 진행한다. 금요일이 되면 변경된 코드를 모두 통합하여 시스템을 빌드하는 작업을 진행한다. 하지만 금요일 안에 모든 작업이 완료되지 못하는 경우가 발생하고, 결국 기존에 계획했던 4일 개발 하루 통합이 지켜지지 못하는 상황이 발.. [Clean Architecture] 컴포넌트 응집도 이번에는 컴포넌트 응집도와 관련된 3가지 원칙을 알아보자. 1. REP(Reuse/Release Equivalence Principle) : 재사용 / 릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다. (당연한 사실!!) 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 한다. 동일한 릴리스로 추적 관리, 동일한 릴리스 문서에 포함되어야 한다. CCP와 CRP는 REP를 엄격하게 제약을 가하는 측면에서 정의한다. .. [Clean Architecture] 컴포넌트 SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해 준다. 큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 컴포넌트란? 컴포넌트는 배포단위이다. 자바에서는 jar파일 루비에서는 gem파일 닷넷에서는 DLL파일 인터프리터형 언어에서는 소스 파일의 결합체 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 컴포넌트의 역사 컴포넌트의 역사를 간단히 훑어보도록 하자. 초기 라이브러리 함수는 소스코드에 직접 포함시켰음. => 메모리크기의 제한으로 인해, 컴파일을 나눠서해야했으므로 컴파일 과정이 매우 느렸음 라이브러리를 소스코드로 부터 분리하고, 미리 별도 컴파일하여.. [Clean Architecture]SOLID 원칙 : 5.DIP 의존성 역전 원칙 DIP 란? 의존성 역전 원칙은 유연성을 극대화시키는데 그 목적이 있다. 이는 소스 코드 의존성이 추상(abstraction)에 의존하며, 구체(concretion)에는 의존하지 않는 시스템을 이야기한다. 즉, 정적 타입의 언어에서는 use, import, include를 통해 인터페이스 혹은 추상 클래스와 같은 추상적인 선언만 참조해야한다는 뜻이다. 하지만 정적타입 언어인 JAVA를 예로들면, String이나 Integer와 같은 구체클래스도 사용하면 안된다는 걸까? 그렇지 않다. String이나 Integer와 같은 클래스는 매우 안정적인 클래스 이기 때문에 변경되는 일이 적다. 따라서 DIP를 논할 때, 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 무시하는 편이다. 즉, 우리가 주의해야할.. [Clean Architecture]SOLID 원칙 : 4.ISP 인터페이스 분리 원칙 ISP 란? 이 단원에서는 책에서 한줄로 명확하게 ISP를 정의하는 문장은 없었으나, 내용상 아래와 같이 요약할 수 있겠다. 유연하며 낮은 결합도가 낮은 구조를 통해 불필요한 의존성을 제거해야한다는 원칙. 책에 있는 위 다이어그램을 통해 ISP를 이해해보도록 하자. (정적 타입 언어를 사용한다 가정) 위 그림을 보게되면, OPS라는 클래스의 인스턴스를 User1, User2, User3라는 프로그램에서 사용하고있다. 이때, User1은 OPS.op1()만, User2는 OPS.op2()만, User3는 OPS.op3()만 사용한다고 가정한다. 위 구조상 User1의 경우 op2와 op3를 사용하지 않음에도 불구하고, op1뿐만 아니라 op2, op3에도 의존성을 가지고 있다. 따라서 op1이 아닌 다른 .. [Clean Architecture]SOLID 원칙 : 3.LSP 리스코프 치환 원칙 LSP 란? 바바라 리스코프라는 사람이 정의한 하위 타입에 대해 먼저 생각해보자 . 여기에서 필요한 것은 다음과 같은 치환 원칙이다. S 타입의 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에서 o2자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다. 말이 쪼금 헷갈리니... 상황을 다시 적어본다면,, 어떤 프로그램 P가 있는데 이게 T타입을 이용해서 만들었고, 만약에 이 T 타입의 객체 o2자리에 S 타입의 객체 o1로 치환해도 P행위가 변하지 않는다면 S는 T의 하위 타입이다... 즉 S는 T를 상속하였고 그 기능들을 다 가지고 있을 것이고, 따라서 S든 T든 P행위에도 영향을 끼치지 않았겠지? 무튼 LSP 원칙이 이러.. 이전 1 2 3 4 다음