본문 바로가기
[책 정리] 10장. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙 - Clean Architecture ISP 와 언어 - 정적 타입 언어는 사용자가 import, user 또는 include 같은 타입 선언문을 사용하도록 강제한다. 이처럼 소스 코드에 포함된 선언문으로 인해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제되는 상황이 무조건 초래된다. 루비나 파이썬 같은 동적 타입 언어에서는 소스 코드에 이러한 선언문이 존재하지 않는다. 대신 런타임 추론이 발생한다. 동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유가 이 때문이다. ISP 와 아키텍처 - 일반적으로, 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다. 소스 코드 의존성의 경우 이는 분명한 사실인데, 불필요한 재컴파일과 재배포를 강제하기 때문.. 2020. 4. 14.
[책 정리] 9장. LSP(Liskov Substitution Principle): 리스코프 치환 원칙 - Clean Architecture - 리스코프는 하위 타입(subtype)을 아래와 같이 정의했다. "여기에서 필요한 것은 다음과 같은 치환(substitution)원칙이다. S 타입의 객체 o1 각각에 대응하는 T타입 객체 o2 가 있고, T타입을 이용해서 정의한 모든 프로그램 P 에서 o2 의 자리에 o1 을 치환하더라도 P 의 행위가 변하지 않는다면, S는 T의 하위 타입이다." 상속을 사용하도록 가이드하기 - 사용자가 Interface 를 바라보면서 어떤 하위타입이 사용되는지에 의존하지 않는다면 이것은 LSP 를 준수한다고 볼 수 있다. 정사각형/직사각형 문제 - LSP 를 위반하는 전형적인 문제로는 유명한 정사각형/직사각형 문제가 있다. Squre 가 Rectangle 을 상속하는 경우.. Rectangle r = ... r.s.. 2020. 4. 13.
[책 정리] 8장. OCP(Open Closed Principle): 개방-폐쇄 원칙 - Clean Architecture - 개방-폐쇄 원칙(OCP) 는 다음과 같다. "소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 다시 말해 소프트웨어 개체의 행위를 확장할 수 있어야 하지만, 이 때 개체를 변경해서는 안 된다." 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문이다. 요구사항을 살짝 확장하는 데 소프트웨어를 엄청나게 수정해야 하면 이는 실패한 아키텍처이다. 사고 실험 - 재무제표를 웹 페이지로 보여주는 시스템이 있다고 하자. 웹 페이지에 표시되는 데이터는 스크롤 할 수 있고, 음수는 빨간색으로 출력한다. 이제 이해관계자가 동일한 정보를 보고서 형태로 변환해서 흑백 프린터로 출력해 달라는 요청이 왔다. 이 보고서에는 페이지 번호가 있어야 하고, 페이지마다 저절한.. 2020. 4. 12.
[책 정리] 7장. SRP(Single Responsibility Principle), 단일 책임 원칙 - Clean Architecture - 좋은 소프트웨어 시스템은 깔끔한 코드(clean code)로부터 시작한다. SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다. SOLID 원칙의 목적은 중간 수준(모듈 수준)의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트 기반이 된다.(재사용성) - SRP: 단일 책임의 원칙. Single Responsibility Principle 각 소프트웨어 모듈은 변경의 이유가 하나, 단 하나여야만 한다. - OCP : 개발, 폐쇄 원칙. Open Closed Principle 기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행.. 2020. 4. 11.
[책 정리] 6장. 함수형 프로그래밍 - Clean Architecture 정수를 제곱하기 - 함수형 언어에서 변수는 변경되지 않는다. 불변성과 아키텍처 - 경합 조건(race condition), 교착 상태(dealock) 조건, 동시 업데이트(concurrent update) 문제가 모두 가변 변수로 인해 발생한다. 우리가 동시성 앱에서 마주치는 모든 문제, 즉 다수의 스레드와 프로세스를 사용하는 앱에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않는다. - 아키텍트라면 동시성(concurrency)문제에 지대한 관심을 가져야만 한다. 우리는 스레드와 프로세스가 여러 개인 상황에서도 설계한 시스템이 여전히 강건하기를 바란다. 가변성의 분리 - 불변성과 관련하여 가장 주요한 타협 중 하나는 앱 또는 앱 내부의 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리하는 일이.. 2020. 4. 10.
[책 정리] 5장. 객체 지향 프로그래밍 - Clean Architecture -좋은 아키텍처를 만드는 일은 객체 지향(Object-oriented) 설계 원칙을 이해하고 응용하는 데서 출발한다. 캡슐화? -OO 프로그래밍은 프로그래머가 충분히 올바르게 행동함으로써 캡슐화된 데이터를 우회해서 사용하지 않을 거라는 믿음을 기반으로 한다.OO 를 제공한다고 주장한 언어들이 실제로는 C언어에서 누렸던 완벽한 캡슐화를 약화시켜 온 것은 틀림없다. 상속? -OO 언어가 더 나은 캡슐화를 제공하지는 못했지만, 상속만큼은 OO 언어가 확실히 제공했다.하지만 상속이란 단순히 어떤 변수와 함수를 하나의 유효 범위로 묶어서 재정의하는 일에 불과하다.OO 언어가 완전히 새로운 개념을 만들지는 못했지만, 데이터 구조에 가면을 씌우는 일을 상당히 편리한 방식으로 제공했다고 볼 수는 있다. 다형성? -함수.. 2020. 4. 9.
[책 정리] 4장. 구조적 프로그래밍 - Clean Architecture 증명 -goto 문장이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 되는 경우가 있다는 사실을 발견했다.만약 모듈을 분해할 수 없다면, 합리적으로 증명할 때 필수적인 기법인 분할 정복 접근법을 사용할 수 없게 된다. -모든 프로그램을 순차(sequence), 분기(selection), 반복(iteration)이라는 세 가지 구조만으로 표현할 수 있다. 해로운 성명서 기능적 분해 -구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻했다.프로그래머는 대규모 시스템을 모듈과 컴포넌트로 나눌 수 있고, 더 나아가 모듈과 컴포넌트는 입증할 수 있는 아주 작은 기능들로 세분화될 수 있다. 엄밀한 증명은 없었다.. 2020. 4. 8.
[책 정리] 3장. 패러다임 개요 - Clean Architecture 구조적 프로그래밍 - 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 객체 지향 프로그래밍 - 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 함수형 프로그래밍 - 함수형 프로그래밍은 할당문에 대해 규칙을 부과한다. 생각할 거리 - 각 패러다임은 프로그래머에게서 권한을 박탈한다. 어느 패러다임도 새로운 권한을 부여하지 않는다. 각 패러다임은 부정적인 의도를 가지는 일종의 추가적인 규칙을 부과한다. 즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안 되는지를 말해준다. - 프로그래밍 패러다임은 앞으로도 딱 세 가지밖에 없을 것이다. 최소한 부정적인 의도를 가진 패러다임으로는 이 세 가지가 전부일 것이다. 결론 - 세 가지 페러다임과 아키텍처의 세.. 2020. 4. 7.
[책 정리] 2장. 두 가지 가치에 대한 이야기 - Clean Architecture -모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공한다.행위(behavior)와 구조(structure)가 바로 그것이다.소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다. 행위 아키텍처 -소프트웨어는 '부드러움을 지니도록' 만들어졌다.소프트웨어는 기계의 행위를 쉽게 변경할 수 있어야 한다.만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면, 우리는 소프트웨어가 아니라 하드웨어라 불렀을 것이다. -소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러워'야 한다.다시 말해 변경하기 쉬워야 한다.이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.이러한 변경사항을 적용하는 데 드는 어려움은 변경되.. 2020. 4. 6.
반응형

티스토리툴바