Solid9 컴포넌트 결합 - SAP (안정된 추상화 원칙) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 고수준의 정책 컴포넌트는 안정된 정도만큼만 추상화 되어야 한다. 시스템에서 업무규칙은 안정된 (I = 0, 즉 불안정성이 작은) 컴포넌트여야 한다. (I 개념을 모른다면 ocwokocw.tistory.com/37 글을 먼저 숙지해야 한다.) 업무규칙은 고수준의 정책이기 때문이다. 반면 불안정한(I = 1) 컴포넌트는 변동성이 큰 컴포넌트여야 한다. 이 문장만 읽었을 때 이상함을 느껴야 한다. "업무규칙은 안정된 컴포넌트 여야 한다"는 말이 당연한 얘기인가? 앞서 SDP 원칙에서 안정된 컴포넌트는 변경을 하기가 어렵다고 하였다. 그런데 SOLID 원칙에서는 고수준의 시스템.. 2021. 2. 10. 설계원칙 - SOLID(DIP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 추상팩토리 패턴:https://ko.wikipedia.org/wiki/%EC%B6%94%EC%83%81_%ED%8C%A9%ED%86%A0%EB%A6%AC_%ED%8C%A8%ED%84%B4 - 개요 DIP는 의존성 역전 원칙이다. 유연성이 극대화된 시스템이란 소스코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템이다. 단어가 어렵더라도 천천히 살펴보자. 우리가 좋아하는 스프링 웹 소스를 떠올려 보자. Controller에서 Service를 호출할 때, Service에 대한 인터페이스를 참조해야지 해당 인터페이스(추상클래스)를 구현한 구체 클래스를 참조해서는 안된다.. 2021. 2. 10. 설계원칙 - SOLID(ISP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 로버튼 C.마틴, ISP vs SRP: https://twitter.com/unclebobmartin/status/996739060348653568 - 개요 위와 같은 다이어그램에서 Employee는 searchByEmployee()를 통해서 제품검색을 하며, Customer는 searchByCustomer()를 그리고 CEO는 report를 보기 위해 generateReport() 함수를 사용한다. Employee, Customer, CEO는 1개의 메소드씩만 사용하지만 ProductService에 함수를 다 정의해놓고 의존하다보니 자신이 사용하지 않는 다른 두 메소드.. 2021. 2. 10. 설계원칙 - SOLID(LSP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://ko.wikipedia.org/wiki/%EC%A7%81%EC%82%AC%EA%B0%81%ED%98%95 - 개요 바바라 리스코프가 하위 타입에 대해 정의한 원칙이다. S 타입의 객체 o1, T 타입의 객체 o2가 있고, T 타입을 이용해서 정의한 프로그램 P에서 o2 대신 o1을 치환해도 P의 행위가 변하지 않는다면, S는 T의 하위타입이다. - LSP 예제 모델들을 관리하는 어플리케이션을 살펴보자. Model 클래스가 있다. 실세계에서는 상당히 많은 메소드가 있겠지만 이 예제에서는 모델 코드를 반환하는 getModelCode() 메소드만 있다고 가정한다.. 2021. 2. 10. 설계원칙 - SOLID(OCP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle - 개요 소프트웨어 개체(클래스, 모듈, 함수)는 확장에는 열려있어야 하며, 변경에는 닫혀 있어야 한다. 즉, 개체의 행위는 확장할 수 있어야 하지만 이때 개체를 변경해서는 안된다. 만약 요구사항 확장하는데 기존 소프트웨어를 많이 수정해야 한다면 안된다는것이다. - 예제 특정 데이터를 가공하여 웹 페이지에 보여주는 시스템이 있다고 하자. 이때 갑자기 이해관계자가 PDF나 Excel 로 보여줄 수 있게 기능을 추가해달라고 한다. 이때 소스코드를 얼마나 변경해야 할까?.. 2021. 2. 10. 설계원칙 - SOLID(SRP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 단일 책임 원칙은 가장 많은 오해를 사고 있는 원칙이다. 이름만 보면 마치 하나의 모듈은 하나의 일만 해야하는 것처럼 느껴진다. 하지만 이는 오해이다. 하나의 모듈은 하나의 액터(사용자 및 이해관계자)에 대해서만 책임져야 한다. 모듈이란 보통의 경우엔 소스파일이다. SRP를 위반하는 원칙들을 살펴보면서 SRP를 이해해보자. - 징후: 우발적 증복 급여 어플리케이션에서 Employee 클래스가 있고, 해당 클래스에서 calculatePay(), reportHours(), save() 메소드를 제공한다고 해보자. 이 클래스는 SRP를 위반한다고 할 수 있는데, diag.. 2021. 2. 10. UML - 유스 케이스 - 개요와 내용 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 유스 케이스 유스 케이스는 시스템의 기능적인 요구사항을 잡아내는 기술이다. 유스케이스는 시스템과 사용자간의 교류를 기술한다. 유스 케이스를 곧바로 판별해내는것은 사실 어려운일이다. 보통은 시나리오를 생각해본 뒤 유스케이스를 식별한다. 시나리오는 사용자와 시스템간의 교류를 단계적으로 나타낸것이다. 예를 들어 온라인 쇼핑몰에서 물건을 산다면 시나리오는 아래와 같다. 고객은 상품 목록을 보고 원하는것을 선택하여 장바구니에 담는다. 물건을 구매하기 위해 배송지 및 신용카드 정보를 기술한다. 시스템은 신용카드 승인을 확인하고 물건 구매 확정을 한다. 그리고 그 결과를 이메일로 발송한다. 위의 시나리오는 개발자가 구현하기 좋은 전.. 2021. 2. 10. UML - 패키지 다이어그램 - 개요와 의존 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 패키지 다이어그램 UML 에서 패키지는 어떤 구성요소라도 더 높은 수준의 단위로 묶을 수 있도록 해주는 구조이다. 각각의 패키지는 네임스페이스를 나타내는데, 이는 모든 클래스가 자신이 속한 패키지내에서 유일해야 한다는 소리이다. 어떤 클래스가 어디에 속하는지를 완벽하게 알기 위해서는 완전한 이름(fully qualified name)을 사용해야 한다. UML 에서 패키지 이름을 나타낼때에는 :: 을 사용한다. Date는 System::Date 와 같이 될 것이다. - 패키지와 의존 규모가 큰 시스템에서는 패키지 다이어그램을 보아야 그 시스템의 구조를 제어할 수 있다. 패키지 다이어그램은 패키지간의 의존을 보여준다. A .. 2021. 2. 10. UML - 클래스 다이어그램과 일반화 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 일반화(Generalization) 일반화의 가장 전형적인 예제는 사업에 대해 개인 고객과 기업 고객에 관한 예제이다. 이 둘의 공통점은 상위 타입(고객)으로 추출하고, 차이점은 하위 타입에서 표현한다. 모델링의 관점에서 고객에 관련된 모든것(연관, 속성, 오퍼레이션)은 기업 고객에 대해서도 성립하는것이다. 소프트웨어 관점에서 일반화는 상속과 관련있다. 상속에서 가장 중요한 원칙은 치환 가능성이다. 치환 가능성이란 만약 고객의 타입으로 참조하여 수행한 오퍼레이션이 있다면, 이 참조하는 인스턴스가 기업 고객이어도 적절하게 동작해야 한다는 의미이다. 고객 Customer와 기업 고객 EnterpriseCustomer가 있다.. 2021. 2. 10. 이전 1 다음
