프레임워크 구축과 발전

본 내용은 월간 마소 2008년 12월호에 실린 내용을 정리한 것입니다.
불펌을 금지하며, 문제시 삭제하겠습니다.

은닉과 캡슐화

  • 은닉 ≠ 캡슐화
  • 은닉
    • 접근 지정자로 구현
    • 접근 지정자로 멤버를 숨기고, 멤버를 제어할 수 있는 인터페이스 노출하는 것
    • 객체를 인터페이스를 통해 노출시켜 동적 바인딩할 수 있게함
  • 캡슐화
    • class로 구현
    • 멤버와 데이터를 class라는 키워드로 묶는 것
    • 그냥 함수의 리턴값을 사용하게 되면 절차적 프로그램이 됨
    • class로 묶으면 데이터의 흐름을 메소드와 데이터로 묶어서 결합도를 낮춰줌

상속과 구성

  • 구현상속 : 부모것을 자식이 사용, 부모클래스를 잘 알고 상속받아야 함
  • 인터페이스 상속 : 인터페이스만 재사용

프레임워크의 구축

  • 조건
    • 확장이 가능해야 함.
    • 기능을 쉽게 대체시켜야 함.
    • 도메인 문제에 대해 추상적이고 필수 구현이 되어 있어야 함.
    • 간단하고 문서화가 잘 되어 있어야 하며 이해하기 쉬워야 함
    • 프레임워크의 작은 부분 전체를 재사용할 수 있어야 함.
  • 커뮤니케이션 중요
    • 프레임워크 개발자에게는 App 개발자가 고객임
    • 도메인 전문가나 해당 App 개발자의 조언 필요
  • 하향식 디자인
    • 도메인 분석 -> 추상화 -> 프레임워크 구현 -> App 구현하여 테스트
  • 상향식 디자인
    • App 구현 -> 계속 구현 -> 반복되거나 비슷한놈은 재사용되므로 프레임워크에 포함
    • 일반적인 개발 방법임

프레임워크의 발전

  • 프레임워크 = 반제품(Semi-Complete Application) : 적은 비용으로 App 만들기 위해 절반정도는 구현되어 있는 수준
  • 랄프존슨의 9가지 패턴을 사용하여 발전할것

 

사용자 삽입 이미지

1) 세가지 애플리케이션 패턴

  • 재사용 부분을 파악하는 일이 중요함 -> 미리 예측이 힘듬
  • 3개 이상의 App을 만들어서 재사용 모듈 파악
  • App과 프레임워크 동시 개발시
    • 일정 Fix시 : 다수의 팀이 나눠서 개발 -> 프레임워크 개발팀 산출물 기다리기 힘드므로 파일럿 프로젝트로 간략하게 살펴봐라
    • 인원 Fix시 : 단일팀이 개발
  • 다수의 App으로 코드를 일반화 할 수록 프레임워크 기능과 품질이 좋아짐. 초기버전이라 불안정하다는 우려도 없앨수 있음 (Pilot Application Pattern)

2) 화이트박스 패턴

  • 두번째 애플리케이션 개발시 시작하면 됨.
  • 첫번째 애플리케이션 만든 후 초기버전 프레임워크 기능을 확장시 “상속”을 사용하라
  • 상속 : 코드를 쉽게 재사용할 수 있게 해줌, 인터페이스를 사용하라. 없으면 구현클래스에서 유추하여 만들어라. 상속을 이용하여 기능 확장 구현을 반복한다.

3) 컴포넌트 라이브러리 패턴

  • 도메인에 특화된 문제의 해결방법이 프레임워크에 들어가지 않아야 함.
  • 재사용하지 않는 클래스는 프레임워크에 넣지않고, 애플리케이션의 구현클래스에 위치
  • 프레임워크의 재사용않는 클래스를 계속 리펙토링

4) 핫 스팟 패턴

  • 화이트박스 패턴으로 계속 추가하고, 컴포넌트 라이브러리 패턴으로 계속 제거 –> 기존 클래스와 추가될 클래스의 관계를 정의하면서 확장하여 중복을 막자
  • 핫 스팟 : 코드 변화가 활발한 부분
  • 화이트박스 패턴으로 자꾸 확장되는 놈은 데코레이션 패턴같은 놈을 사용하여 구현 가능.

5) 플러그러블 오브젝트 패턴

  • 구현클래스의 소소한 변경이 많으면 –> 프레임워크 커짐 –> 복잡도 증가 –> 프레임워크 사용 어려움
  • 객체 생성시 다양성 구분에 필요한 인자 사용 –> 객체가 인자에 따라 행동하게 개발
  • 인자 : 상수, 심볼, 클래스 래퍼런스, 인스턴스 변수, 함수 포인터, 함수자…..

6) 파인-그레인드 패턴

  • 간단한 API가 복잡한 API보다 사용하기 쉽다 –> Small Objects Pattern
  • 객체는 커질수록 –> 중복기능 많아짐, 중복코드 많아짐, 도메인 문제를 다룰려고 하는 경향이 있음. –> 리팩토링 대상임

7) 블랙박스 패턴

  • 애플리케이션은 요구변경에 유연해야 함 –> 클래스의 확장에는 열려있고, 수정에는 닫혀 있어야 함. –> 상속보다는 구성을 사용

8) 비주얼 빌더 패턴과 언어 도구 패턴

  • 비주얼 빌더 패턴 : 프레임워크 정리한 문서, 프레임워크 사용을 도와주는 툴 제공할것
  • 언어 도구 패턴 : 애플리케이션 점검 툴, 디버깅 툴 제공할 것

 

 

이러다 미쳐 내가 ~

 

사용자 삽입 이미지

CC BY-NC-ND 2.0 KR

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스

저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.

댓글 남기기