프로그래밍에서 사용되는 응집도과 결합도에 대해 살펴보자참고로 좋은 아키텍처는 높은 응집도와 낮은 결합도를 추구한다.응집도관련 요소가 얼마나 한 모듈에 모여 있는가를 나타낸다.메서드, 함수 수준부터 크게는 모듈 수준에 이르기까지 모든 수준에서 응집도를 판단할 수 있다.몇 가지 기준을 대입해서 생각해보면 응집도를 판단하는데 도움이 된다.관련 코드가 한 패키지(또는 한 모듈)에 모여 있는가?관련 코드가 한 클래스에 모여 있는가?관련 코드가 한 함수에 모여 있는가?관련 코드가 한 패키지에 모여 있는가?카드가 등록되고 등록 결과를 SMS에 전송하는 기능이 필요하다고 하자.만약 카드가 등록되고 SMS 전송이 필요하니 SMS 전송기능이 card 패키지안에 있다면 응집도가 낮다고 볼 수 있다.통지 전송 관련 기능이 c..
프로그래밍 노트/아키텍처
아키텍처란? 시스템 아키텍처는 시스템의 동작 여부와 거의 관련이 없다. (아무런 역할을 하지 않는다는건 아니다.) 형편 없는 아키텍처를 갖춘 시스템도 그런대로 잘 동작한다. 이런 시스템은 운영보다는 배포, 유지보수, 계속되는 개발 과정에서 어려움을 겪는다. 유지보수는 모든 측면에서 봤을 때 비용이 가장 많이 발생한다. 유지보수 중 가장 큰 비용은 탐사와 이로 인한 위험부담에 있다. 탐사? 기존 소프트웨어를 파헤쳐서 어디를 고치는게 최선/최적일지 결정하는 비용 이러한 변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성이 존재하며, 이로 인한 위험부담 비용이 추가됨 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리하면 비용을 줄일 수 있음 선택사항 열어 두기 소프트웨어는 두 가지 가치 행..
SOLID원칙이 벽과 방에 벽돌을 배치하는 방법이라면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다. 큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 자바의 경우 jar 파일이 컴포넌트 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 소프트웨어 엔지니어링 원칙의 도움이 필요하다. 컴포넌트 응집도와 관련된 세 가지 원칙 REP : 재사용/릴리스 등가 원칙 (Reuse/Release Equivalence Principle) CCP : 공통 폐쇄 원칙 (Common Closure Principle) CRP : 공통 재사용 원칙 (Common Reuse Principle) REP: 재사용..
SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. 중간 수준? - 모듈 수준에서 작업할 때 적용할 수 있음. 즉, 코드 수준보다는 조금 상위에서 적용되며 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는데 도움을 줌 단일 책임 원칙 (SRP - Single Responsibility Principle) 하나의 모듈(단일 모듈)은 변경의 이유가 오직 하나뿐이어야 한다. 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다. 액터? 해당 변경을 요청하는 집단을 뜻함 모듈이 단 하나의 일만 해야 한다라는 뜻이 아니다. 단 하나의 일만 해야하는 원칙은 함수다. 함수는..
객체 지향 프로그래밍 1966년 등장 알골(ALGOL)언어의 함수 호출 스택 프레임(stack frame)을 힙(heap)으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견 이러한 함수가 클래스의 생성자, 지역 변수는 인스턴스 변수, 중첩 함수는 메소드가 되었음 객체 지향(Object-Oriented)란 무엇일까? 데이터와 함수의 조합? 그다지 만족스러운 대답은 아님, OOP 등장 이전에도 프로그래머는 데이터 구조를 함수에 전달해 왔다. 실제 세계를 모델링하는 새로운 방법? "실제 세계를 모델링한다"라는 말은 무엇을 의미하는 걸까? 왜 우리는 그 방향을 추구해야하는가? OO는 현실 세계와 의미적으로 가깝기 때문에 OO를 사용하면 소프트웨어를 좀 더 쉽게..
소프트웨어 개발자는 행위(behavior), 구조(structure)이 두 가지 가치를 반드시 높게 유지해야 하는 책임을 가진다. 행위에만 집중하게 된다면 소프트웨어 시스템은 쓸모없게 된다. 행위, 동작(Behavior) 프로그래머는 이해관계자나 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다. 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다. 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각하지만(버그 수정 및 기능 개발), 이 것은 틀렸다. 아키텍처(Architecture) 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러워야 한다. 다시 말해 변경하기 쉬어야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 변경사항을 간단하고 쉽게 적용할..
설계(design)와 아키텍처(architecture) 설계와 아키텍처에는 아무런 차이가 없다. 단지.. 아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬때 흔히 사용되며 설계는 저수준의 구조 또는 결정사항 등을 의미할 때 많이 사용된다. 좋은 소프트웨어 설계의 목표? 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는데 있다. 좋은 아키텍처? 좋은 소프트웨어? 왜 좋은 소프트웨어를 만들어야 하는가?라는 질문이 거창한 대답을 요구할 것 같지만 결론은 유지보수 비용을 줄이기 위함이다. 아무리 복잡한 프로젝트여도 말이다. 생각해봐야 할 점 소프트웨어 제품이 잘 팔린다 -> 엔지니어링 직원 수를 뽑아 제품을 개발한다 -> 시간이 지날수록 코드 라인당 비..
