아키텍처와 설계는 크게 다르지 않다. 다르다기 보단 연속성을 가지고 이어져있다고 보는 것이 옳다.저수준의 세부사항(설계)로 이루어진 고수준의 결정사항(아키텍처)이다.소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수 하는 데 투입되는 인력을 최소화하는 데 있다
모든 소프트웨어 시스템은 두가지 가치를 제공한다 - 행위와 구조행위 - 소프트웨어에 담긴 이해관계자의 요구사항이 행위를 구현하는 것이 프로그래머가 해야하는 전부가 아님구조 - 아키텍처확장성이 중요하다.변경하기 쉬워야 한다시스템의 형태와 요구사항의 형태가 맞아야한다.긴급
goto문이 해롭다는 것을 파악하고, if/then/else나 do/while/until 구조로 대체했다.구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.객체지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.함수형 프로그래밍은 할당문
데이크스트는 수학적으로 증명하려고 했다. 세가지 방법을 이용해서 증명하려고 했는데,순차 구문 (열거법)분기반복 - 귀납법 사용이 세 개를 이용해서 프로그래밍을 유클리드 계층구조로 만들려고 했다.goto문의 해로움을 알렸다. 그러면서 프로그래밍 성장을 이뤘다. goto문
객체지향 OO 설계 원칙은 캡슐화/상속/다형성을 지원해야한다. 캡슐화 데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선을 그을 수 있다. OO언어에서는, 각각 클래스의 private 멤버 데이터와 public 멤버 함수로 표현된다. 그렇지만 OO언어에서만, 캡슐화가 되는건 아니다. 위의 c언어의 경우, pointer.h를 사용하는 측에...
클로저를 이용한 제곱함수를 설명한다.여기서 특징은, 자바와 다르게 , 가변변수를 허용하지 않는다는 점이다.아키텍처는 변수의 가변성을 염려한다.그 이유는 경합 조건, 교착상태 조건, 동시 업데이트 문제가 모두 가변 변수로 인해 발생하기 때문이다.경합조건 / 교착상태 조건
SRP 단일 책임 원칙은 단 하나의 일만 해야한다는 원칙이 아니다.→ 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다.그림 7.1을 보면, Employee 클래스에 calculatePay(), reportHours(), save() 이 세 개의 메서드가 있다.
개방-폐쇄 원칙은 확장에는 열려 있어야하고, 변경에는 닫혀 있어야 한다.소프트웨어 아키텍처가 훌륭하다면, 변경되는 코드의 양이 가능한 한 최소화 될 것이다. 이상적인 변경량은 0 이다.변경되는 요소를 적절하게 분리하고 (SRP), 이들 사이의 의존성을 체계화하면(DIP
User1은 op1메서드만, User2은 op2메서드만, User3은 op3메서드만 사용한다고 가정하자.op2를 수정 재배포를 할 경우, User1과 User3은 op2를 사용하지 않음에도 불구하고, 재 컴파일 후 다시 배포해야한다.이는 의존성 문제인데, 불필요한 의존
의존성 역전 원칙이란, 의존성이 추상에 의존하고 구체적인 것에 의존하지 않아야 한다는 원칙이다.이는, 100프로 지켜지기는 힘들다. 예를 들어, JAVA에서 string은 구체적인 클래스이나, 안정하기 때문에 추상클래스로 만들지 않는다.따라서, 의존성을 피해야 하는 것
컴포넌트 : 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위잘 설계된 컴포넌트는 반드시 독립적으로 배포가 가능해야 하며, 독립적으로 개발 가능한 능력을 갖춰야한다.개발 초창기에는 프로그램이 로드될 주소를 직접 제어해야 했기에, 메모리 사용량이 점점 늘어났다.재배치
재사용 단위는 릴리스 단위와 같다아키텍처의 관점에서 단일 컴포넌트는 응집성 높은 클래스&모듈로 구성되어야 한다.즉, 공유하는 중요한 테마나 목적이 같은 것끼리 구성되어야한다는 뜻이다.따라서, 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같고, 동일한 릴리스로 추
컴포넌트 의존성 그래프에 순환이 있어서는 안된다.동일한 소스코드를 여럿이 건드리면, 서로의 코드에 의존성이 생길 수 있다. 이때, 해결책으로는 두가지가 있다.중간규모 프로젝트에서 흔히 사용월-목에 각자 코딩, 금 - 통합 및 빌드장점 : 빠른 피드백 및 서로 신경안쓰고
한 줄 요약 : 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는데에 있다.시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있도록 해야한다.소프트웨어 아키텍처는 쉽게 배포할 수 있도록 만들어야 한다. 배포 비용이
한 줄 요약 : 좋은 아키텍트는 시스템의 유스케이스 / 운영 / 개발 / 배포를 지원해야한다. 또한 뛰어난 아키텍트라면 이러한 변경을 예측하여 큰 무리 없이 반영할 수 있도록 만들어야 한다.행위를 명확히 하고 외부로 드러내며, 시스템의 의도를 아키텍처 수준에서 알아볼