의존 관계
- "소프트웨어는 무조건 변한다."
: 요구사항, 기술, 프레임워크, 데이터베이스, 프로토콜, 정책 등이 달라짐에 따라 소프트웨어 구조가 변경될 수 있음을 항상 염두해야 한다. - 즉 새로운 의존 관계를 생산하거나, 기존 의존 관계를 변경시킨다.
- 의존 관계에 대처하는 자세
- 변경을 예측하고 이를 반영하여 설계 => Design pattern
- 변경에 쉽게 적응할 수 있도록 단순하게 (다시) 설계 => Refactoring
응집도(cohesion), 결합도(coupling)
- 응집도
- 하나의 모듈이 하나의 기능(책임)을 온전히 담당하고 있는 정도
- 응집이 잘 될수록 기능이 명확하다.
- 결합도
- 모듈 간의 서로 다른 기능(책임)들이 얽혀 있는 상호 의존도의 정도
- 다른 모듈에 대해 필요한 정보만 알아야 한다.
source: https://medium.com/@jang.wangsu/%EC%84%A4%EA%B3%84-%EC%9A%A9%EC%96%B4-%EC%9D%91%EC%A7%91%EB%8F%84%EC%99%80-%EA%B2%B0%ED%95%A9%EB%8F%84-b5e2b7b210ff
- 응집도가 낮은 모듈은..
- 이해하기 어렵다.
- 재사용하기 힘들다.
- 유지보수가 힘들다
- 다른 모듈의 변화에 민감하다.
- 결합도가 높은 모듈은..
- 연관된 모듈이 변경되면 더불어 변경해야 한다.
- 해당 모듈을 이해하기 위해 다른 모듈을 함께 이해해야만 한다.
- 다른 프로그램이 모듈 재사용이 어렵다.
소프트웨어는 응집도는 높게, 결합도는 낮게 설계하는 것이 이상적이다.
좋은 설계란 "변경"과 관련된다. 즉 응집도와 결합도는 변경과 관련된 것이고, 응집도를 높게, 결합도를 낮게 설계함으로써 소프트웨어의 변경에 민감하지 않고, 수정에 용이하도록 하는 이상적인 설계를 하는 것이다.
좋은 캡슐화(Encapsulation)을 통해 높은 응집과 낮은 결합을 달성할 수 있다.
아키텍쳐, 디자인 패턴, 마이크로 패턴
소프트웨어 아키텍쳐란?
- SW 시스템을 구성하는 서브시스템과 컴포넌트, 그리고 그것들의 관계를 나타내는 용어 - "Patter Oriented Software Architecture"
- 시스템을 구성하는 구성 요소와 구성 요소 간의 관계를 나타냄
디자인 패턴이란?
- 특정한 전후 관계에서 일반적인 설계 문제를 해결하기 위해 상호 교류하는 수정 가능한 객체와 클래스들의 설명 - "Design Patterns, GoF"
- 디자인 패턴은 아키텍쳐 내부를 구성하는 컴포넌트 혹은 클래스를 식별하고 이들의 관계를 정의
- 복잡한 구조를 한 단어로 정의, 소프트웨어 설계에 관한 의사소통을 효율적으로 하게 도와준다.
마이크로 패턴이란?
- Idiom으로 많이 알려짐.
- 개발 언어에 종속적인 패턴
- 패턴에서 일상적으로 사용하게 되어 언어에 내장된 패턴, 즉 코딩방법을 패턴화한 것이다.
- ex) Pimpl Idiom (Bridge Pattern)
아키텍쳐 vs 설계
- 아키텍쳐는 설계지만, 모든 설계가 아키텍쳐는 아니다.
- 아키텍쳐는 설계 및 구현을 위한 제약 사항을 부여하고, 설계는 아키넥쳐의 제약 사항을 준수해야 한다. 하지만 아키텍쳐적으로 중요하지 않다면 설계에서 자유롭게 결정할 수 있다.
프레임워크(Framework)란?
-
애플리케이션 개발에 바탕이 되는 템플릿과 같은 역할을 하는 클래스들과 인터페이스의 집합 - "Erich Gamma"
-
소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것 - "Ralph Johnson"
-
도메인 내의 애플리케이션을 위해 확장 가능한 툴을 제공하는 아키텍처 패턴 - "UML User Guide"
-
프레임워크는 설계를 추상적인 클래스로 분리하고 그들의 책임과 협동 관계를 정의함으로써 아키텍처적인 가이드를 제공 - "Design Patters"
-
특징
- 애플리케이션의 틀과 구조를 결정하고, 개발자의 코드를 제어한다.
- 구체적이며 확장 가능한 기반 코드를 제공한다.
- 설계자가 의도하는 여러 디자인 패턴의 집합으로 구성되었다.
프레임워크를 사용하는 이유
- 모듈화
: 구현을 인터페이스 뒤에 감추는 캡슐화를 통해 모듈화를 높인다. - 재사용
: 프레임워크가 제공하는 인터페이스를 구현함으로써 동일 도메인에 존재하는 애플리케이션에 반복적으로 재사용할 수 있다.
=> 도메인 지식과 경험이 있는 개발자의 노력을 재활용 - 확장성
: 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 확장할 수 있도록 한다.
reference: https://private.tistory.com/8
거대하고 복잡도가 높은 프로젝트를 하기 위해 필요한 많은 개발자들이 통일성 있게 빠르게 안정적으로 개발할 수 있다.
중복되고 뒷단을 처리하는 부분을 프레임워크가 처리해주고, 개발자는 비즈니스 모델에만 집중할 수 있는 구조를 갖추고 있다.
프레임워크가 가져야 할 특징
- 개발자들이 따라야 하는 가이드라인을 가진다. 개발자가 많이 투입되어야 하는 프로젝트의 경우, 개발자가 늘어남에 따라 전체 시스템의 통합성, 일관성이 부족해지게 된다. 따라서 개발자의 자유를 제한하기 위해 프레임워크를 도입한다.
- 개발할 수 있는 범위가 정해져 있다.
- 개발자를 위한 다양한 도구들이 지원된다.
프레임워크와 라이브러리의 차이점
제어 흐름에 대한 주도성이 누구에게/어디에 있는가에 차이를 보인다.
라이브러리는 개발자의 소스코드에 포함하여 호출되지만, 프레임워크는 그 틀 안에 개발자의 코드가 포함되는 것이다.
즉 애플리케이션의 흐름의 관점에서, 프레임워크는 전체적인 흐름을 스스로 쥐고 있고 개발자는 그 틀 안에서 필요한 코드를 작성하고 구현하는 반면 라이브러리는 개발자가 전체적인 흐름을 구현하며 라이브러리를 가져다 쓰는 것이다.
