학습목표
* SW 재사용성을 높일수 있는 방안에 대해 이해할 수 있습니다.
* 디자인패턴과 프레임워크의 관련성에 대해 이해할 수 있습니다.
* 프레임워크 구성요소와 종류에 대해 이해할 수 있습니다.
SW 재사용 방안들
* copy & paste
* method(function)
* class(Inheritance)
* AOP
SW 재사용성을 높일수 있는 방안
copy&paste
초보적인 재사용 방식으로 비슷한 예제를 다른소스에 복사해서 사용 이경우 하나 바뀌어야하는 상황이 올경우 모두 변경해야함
method 호출
자주사용되고, 유사한 기능을 모아 메서드로 정의하여 재사용. 메서드 내부에 반복되는코드를 씀. 이걸 호출해서 씀 메서드의 signature가 변경될경우 이 메서드가 사용되는 모든 클래스에 영향을 줌. 메서드 재사용 방법은 copy&paste보다 진보된 방식이지만, 작업 영역간의 결합도문제는 여전히 존재한다.
클래스 재사용(상속)
상속받은 클래스들은 부모클래스의 메서드를 사용할 수 있음. 하지만 부모클래스의 메서드의 signature가 변경될경우 하위클래스가 영향받기때문에 여전히 존재한다.
AOP(Aspect Oriented Programming)
OOP를 대체하는 개념은아니고 서포트해주는 개념. 좀더 OOP스러워짐.
AOP는 관심사를 분리. 핵심관리모듈과 횡단관심모듈을 분리한다. 횡단관심모듈은 핵심관심모듈을 가로지르는 모듈임. 핵심관심모듈은 비지니스로직, 횡단관심모듈은 비지니스로직을 서포트해주는 기능적인 모듈. 이 핵심관심모듈과 횡단관심모듈을 합쳐주는걸 위빙이라한다. 이것은 프레임워크에서 해준다.
디자인패턴과 프레임워크의 관련성
디자인 패턴의 정의
1.프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중
하나로, 소프트웨어 개발과정에서 발견된 Know-How를 축적하여
이름을 붙여 이후에 재사용하기 좋은 형태로 특정 규약을 묶어서 정리한것.
2.이 용어를 소프트웨어 개발 영역에서 구체적으로 처음 제시한 곳은,
GOF(Gang of Four)라 불리는 네명의 컴퓨터 과학 연구자들이 쓴 서적
이다.23가지의 디자인패턴을 제공한다.
Design Patterns : Elements of Reusable Object-Oriented Software(재사용 가능한 객체지향 소프트웨어의 요소-디자인패턴)
디자인 패턴을 사용하는 이유
*요구사항은 수시로 변경 -> 요구사항 변경에 대한 소스코드변경 최소화
*여러사람이 같이하는 팀프로젝트 진행 -> 범용적인 코딩스타일 적용
*상황에 따라 인수인계하는 경우도 발생 -> 직관적인 코드사용
프레임워크의 정의
1.비기능적(NoN-functional) 요구사항(성능, 보안, 확장성, 안정성 등)을 만족하는 구조와 구현된 기능을 안정적으로 실행하도록 제어해주는 잘 만들어진 구조의 라이브러리의 덩어리
2.프레임워크는 어플들의 최소한의 공통점을 찾아 하부구조를 제공함으로써
개발자들로 하여금 시스템의 하부구조를 구현하는데 들어가는 노력을 절감하게 해준다.
프레임워크를 사용하는 이유
1.비기능적인 요소(보안,로깅 등등)들을 초기 개발단계마다 구현해야 하는
불합리함을 극복해준다.
2.기능적인 요구사항에 집중할 수 있도록 해준다.
3.디자인패턴과 마찬가지로 반복적으로 발견되는 문제를 해결하기 위한
특화된 Solution을 제공한다.
디자인패턴과 프레임워크의 관련성
1.디자인 패턴은 프레임워크의 핵심적인 특징이고, 프레임워크를 사용하는
애플리케이션에 그 패턴이 적용된다는 특징을 가지고 있다.
2.하지만 프레임워크는 디자인 패턴이 아니다.
1. 디자인 패턴은 애플리케이션을 설계할 때 필요한 구조적인 가이드라인이 되어줄 수는 있지만 구체적으로 구현된 기반코드를 제공하지 않는다.
2. 프레임워크는 디자인 패턴과 함께 패턴이 적용 된 기반클래스 라이브러리를 제공해서 프레임워크를 사용하는 구조적인 틀과 구현코드를 함께 제공한다.
개발자는 프레임워크의 기반코드를 확장하여 사용하면서 자연스럽게 그 프레임워크에서 사용된 패턴을 적용할 수 있게 된다.
프레임워크의 구성요소와 종류
IOC, Class Library, Design Pattern
IoC(Inversion of Control)
IoC란 "제어의 역전" 즉, 인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해준다는 뜻으로,
컨테이너 역할을 해주는 프레임워크에게 제어하는 권한을 넘겨서 개발자의 코드가 신경써야 할 것을 줄이는 전략이다.*
1.원래는 개발자가 주도권을 쥐고있었는데 프레임워크에게 뺏김으로 제어의 역전이 발생하여 제어의 역전이라함.
2.프레임워크의 동작원리를 제어흐름이 일반적인 프로그램 흐름과 반대로 동작하므로 IoC라고 설명함.
3.스프링 컨테이너는 IoC를 지원하며, 메타데이터(XML설정)을 통해 beans를 관리하고 어플리케이션의 중요부분 형성
4.스프링 컨테이너는 관리되는 bean들을 의존성 주입을 통해 IoC를지원함.
클래스 라이브러리(Class Library)
1.프레임워크는 특정부분의 기술적인 구현을 라이브러리 형태로 제공한다.
2.클래스 라이브러리 라는 구성요소는 프레임워크 정의중 하나인 "Semi Complete(반제품)"이다. 라고 해석하게 만들었다.
특징 | 프레임워크 | 라이브러리 |
---|---|---|
유저코드의 작성 | 프레임워크 클래스를 서브클래싱 해서 작성 | 독립적으로 작성 |
호출 흐름 | 프레임워크 코드가 유저코드를 호출 | 유저코드가 라이브러리를 호출 |
실행 흐름 | 프레임워크가 제어 | 유저코드가 제어 |
객체의 연동 | 구조프레임워크가 정의 | 독자적으로 정의 |
라이브러리와 프레임워크의 차이점
1.프레임워크와 라이브러리를 구분하는 방법은 실행제어가 어디서 일어나는가에 달려있다.
2.라이브러리는 개발자가 만든 클래스에서 직접 호출하여 사용하므로 제어를 개발자의 코드가 관장하고 있다.
3.프레임워크는 반대로 프레임워크에서 개발자가 만든 클래스를 호출하여 실행의 흐름에 대한 제어를 담당한다.
디자인 패턴
1.프레임워크는 디자인패턴과 그것이 적용된 기반 라이브러리의 결합으로 이해할 수 있다.
2.프레임워크의 라이브러리를 살펴볼때도 적용된 패턴을 주목해서 살펴본다면 그 구성을 이해하기 쉽다.
3.특히 프레임워크를 확장하거나 커스터마이징 할때는 프레임워크에 적용된 패턴에 대한 이해가 꼭 필요하다. >디자인패턴 + 라이브러리 = 프레임워크
프레임워크 종류
아키텍쳐 결정 = 사용하는 프레임워크의 종류 + 사용전략
기능 | 프레임워크 종류 |
---|---|
웹(MVC) | Spring MVC, Struts2, Webwork.. |
OR매핑 | MyBatis,Hibernate,JPA,SpringJDBC |
AOP | Spring AOP,AspectJ,JBoss AOP |
DI | Spring DI, Google Guice |
Build와 Library관리 | Ant + Ivy,Maven,Gradle |
단위테스트 | JUnit, TestNG,Cactus |
JavaScript | jQuery,AngularJS,Node,js |