[IT/개발] 라이브러리와 프레임워크 이해

프레임워크를 만들었음에도 불구하고 초기 프레임워크 ㅐ념이 나올 때의 글만 보다가 요즘 다시 보니 새로운 느낌까지 들고 너무 책을 등한시 했다는 생각이 든다.
출퇴근시간이 1시간이상 소요되는 되다가 저녁먹고 나서는 건강을 위해서 운동을 해야하고
요즘 경제서적보랴 ... 한동안 등한시 해왔던 개발이론 분야....
다시 책을 집어 들고 인터넷에서 여러 개발자분들의 노고를 감사히 읽으면서 이해를 해야겠다.

프레임워크 생산성의 향상

•프로그램에서의 생산성 향상 방안 : 코드의 재사용
•Function, Procedure 개념 지원 언어의 출현, 이후 객체지향 언어가 출현
•컴포넌트 사용 : 재사용을 높이고 검증된 코드를 사용하게됨 --> SW 품질이 높아지고 개발비용/유지비용이 낮아짐
•컴포넌트 재활용과 디자인 재활용
•객체지향 프로그램에서는..
•클래스 : 기능을 모듈화 & 추상화 지원
•추상클래스 : 객체간 프로토콜 일치 가능
•동적바인딩 : 프로시저 호출 지연 바인딩(Late-binding)
•클래스 상속 : 서브클래스에서 기능을 추가/보완
•다형성 : 객체의 기능을 교체
•랄프존슨이 말한 프레임워크
•추상클래스들의 집합과 상호 협조하는 클래스들의 인스턴스 동작방법으로 이루어진 재사용 가능한 디자인
•예제) 윈도우 애플리케이션용 프레임워크
•화면의 로직처리
•윈도우 그리는 컴포넌트
•통신 컴포넌트
•내부 정보 처리하는 도큐먼트 컴포넌트
•등등등..

Framework이란 무엇인가? 

 Ralph Johnson 이라는 사람은 추상클레스( abstract class) 들의 집합과 상호 협조하는 클래스들의 인스턴스 동작 방법으로 이루어진 재사용 가능한 디자인이라 정의.

프로젝트에 어울리는 잘 만들어진 프레임워크를 이용한 어플리케이션은 비록 거대해지더라도 프레임워크의 의도에 맞게 어플리케이션의 설계가 이루어짐. 때문에 어플리케이션에 의해 System의 안정성을 해치거나, 터무니없이 낮은 퍼포먼스를 내는 일은 거의 없을 것 임.

라이브러리와 프레임워크의 차이!
라이브러리는 개별적인 기능들을 집단형태로 묶음을 의미.
때문에 라이브러리를 이용해 문제를 해결하고자 할때는 메소드의 기능을 정확히 이해하고 사용해야 함.
프레임워크는 원하는 기능을 제공하는 모듈의 인스턴스와 이에 수반되는 여러가지 장치 들의 상호작용까지의 묶어서 정의 하게 됨.때문에 프레임워크에서 제공되는 기능을 사용하게 되면 이와 수반된 이미 검증된 작업의 플로우까지 함께 사용하게 되는 것입니다.
이렇게 함으로 해서 어플리케이션의 코드를 줄일 수 있고, 안정성을 높이며 개발 속도를  빠르게 할 수 있습니다.


라이브러리 대신 프레임워크 사용하는 이유

•라이브러리
•정의 : 해결하고자 하는 도메인 문제와 상관없이 재사용할 컴포넌트의 집합
•사용시 : 제공하는 메소드의 기능을 정확히 알고 있어야 함 (목적, 인자, 결과값)
•프레임워크
•정의 : 해결하고자 하는 도메인 문제에 특화된 인스턴스들이 함께 동작되는 컴포넌트 집합과 디자인
•사용시 : 필요한 지점에서 적절히 삽입하고 쉬운 사용, 세부적인 부분은 몰라도 됨
•프레임워크 = 반제품(Semi-Complete Application) : 적은 비용으로 App 만들기 위해 절반정도는 구현되어 있는 수준

•예제 : 신뢰성 있는 메시징, 트랜젝션 개발시
•라이브러리 : 각 라이브러리별 메소드를 알고, 개발해야 됨
•프레임워크 : WCF 쓰면 내부의 세부사항은 몰라도 기능 흐름만 파악하면 되며, 코드가 주어듬

좋은 프레임워크와 효과적인 사용법

•일반적인 프레임워크 사용방법
•1) 클래스의 서브클래스 생성
•2) 생성된 객체의 내부환경을 설정
•3) 프레임워크가 제시하는 표준 방법으로 App에 적용
•좋은 프레임워크의 요소
•효율성(Effectiveness) : 개발자에게 효율적이여야, 개발 속도를 빠르게 해야, 개발비용을 줄여야 함
•확장성(Extensibility) : 특정 도메인의 App 개발시 개발항목을 포괄하는 확장성을 가져야 함 (App이 삼각형 윈도우를 지원해야 한다는 식의 무리한 확장성은 포함 안해도 됨)
•적용규모(Coverage) : 구현사항을 어느 범위까지 적용할지?
•평이성(Simplicity)와 이해도(Understandability) : 교육이 쉬워야, 너무 복잡하거나 추상적이면 안됨
•통합성(Framework Intergration) : 다른 프레임워크나 라이브러리와 상호소통이 잘되면 좋다
•품질(Qualities) : 능률성,적용성,표준성.. 필수항목은 아닌듯
•안정성(Stability) : 개발코드에 정확한 계산과 결과물 도출

프레임워크 도입시 고려할 점

•필요이상으로 복잡해지고 코드나 객체가 커지면 안됨
•랄프존슨 : "원할하게 일할 수 있을 만큼 이 프레임워크가 쉽게 느껴지는가?"
•프레임워크 도입시 더 비효율적이 될거 같으면 때려치워라! (개발비용, 교육, 문서화 작업 등...)

프레임워크 만들기

•추상 개념을 먼저 생각하기는 어렵다.. 먼저 구현해 보자
•먼저 구현 -> 문제 해결 방법을 작은 집합으로 나눔 -> 구현체 중 컨텍스트를 인자화해 변경할 수 있도록 수정
•도메인 전문가가 만들때 : Up-Front 디자인 방식
•코딩 전문가가 만들때
•반복적인 구현을 통해 코드를 개선해 나감
•반복 개발시 Hot Spots과 Frozen Spots를 잘 구분해서 다음번 개발시 잘 구성하자
•App이 다 만들어지면 이전 프레임워크와 비교하여 재사용성 부분을 반영
•구현클래스에서 추상클래스 유추하기
•구현클래스에서 일반적인 부분들을 뽑아서 추상클래스 만들기
•1) 공통 기능의 구현클래스 준비
•2) 구현 클래스의 공통 기능을 하나의 메소드로 옮긴다.
•3) 옮겨진 구현 클래스의 멤버로 있는 메소드의 이름을 동일하게
•4) 이름을 변경한 메소드의 인자, 리턴값을 동일하게 일반화
•5) 해당 메소드를 분리하거나 병합할 필요시 리팩토링
•6) 같은 메소드명이지만 다른 구현이라면 추상클래스에서 메소드명을 반영
•7) 구현 클래스의 메소드 내용이 같다면 수퍼클래스로 구현을 옮김
•상향식 설계
•하향식 : 구현 클래스 먼저 만들고 이를 바탕으로 추상클래스 만듬
•상향식보다 쉽다.
•R = I + J = AX + AY = A(X + Y) --> 여기서 A는 공통부분

필요한 설계 원칙
 
•의존 관계 역전 원칙(The Dependency Inversion Principle)
•인터페이스 분리 원칙(The Interface Segregation Principle)
•리스코프 치환 원칙(The Liskov Substitution Principle)
•단일 책임 원칙(The Single Responsibility Principle)
•개방 폐쇄 원칙(The Open-Closed Principle)

프레임워크 개발의 9 단계

•http://st-www.cs.illinois.edu/users/droberts/evolve.html
•시간축에 따라 동시에 진행할 수도 있다.
•1) Three Example : 세가지 애플리케이션 패턴
•2) White-box Framwork : 화이트박스 패턴
•3) Component Library : 컴포넌트 라이브러리 패턴
•4) Hot Spots : 핫 스팟 패턴
•5) Pluggable Object : 플러그러블 오브젝트 패턴
•6) Fine-grained Object : 파인-그레인드 객체 패턴
•7) Black-box Framework : 블랙박스 패턴
•8) Visual Builder : 비주얼 빌더 패턴
•9) Language Tools : 언어도구 패턴

프레임워크 개발은 여러 도메인에 대하여 여러가지 문제를해결할 수 있도록 만들어지기 때문에 특정 도메인의 간단한 문제를 해결하기 위하여 기능과 구현이 복잡해지고 코드의 크기나 객체의 크기가 커질 수도 있음.