프레임워크(framework)

틀 구조, 뼈대, 골격, 구조, 구성

• 일을 하는데 있어 어떤 틀 구조가 정해져 있고 이에 맞춰 일을 할 수 있게끔 구성되어 있는 환경
• 프레임워크로 인해 보다 쉽게 서비스느 애플리케이션을 구축할 수 있다

소프트웨어의 특정한 클래스에 대하여 재사용할 수 있는 설계로 구성된 관련된 클래스들의 집합

아키텍처적인 가이드를 제공

이점

모듈화, 재사용성, 확장성
인터페이스 뒤에 감추는 캡슐화로 모듈화(modularity)를 강화

• 설계와 구현의 변경에 따르는 영향을 국소화시키며 이는 품질을 향상시킨다

프레임워크가 제공하는 인터페이스는 여러 애플리케이션에서 반복적으로 사용할 수 있는 일반적인 컴포넌트를 제공하며 재사용성(reusability)을 높여준다

• 개발 번복을 줄여준다(설계부터 유효성 확인, 테스트 등의 과정을 반복하지 않을 수 있게 된다
• 생산성 증가

다형성(polymorphism)을 통한 애플리케이션의 확장성(extensibility) 증대

개발 생산성 증대에 큰 도움을 준다

vs 공통 라이브러리

공통 라이브러리(common library)와는 다름

라이브러리는 애플리케이션에서 공통적으로 사용할 수 있는 함수들의 집합

• 필요할 때마다 호출해 사용하기 때문에 제어의 흐름은 애플리케이션에서 공통 라이브러리로 이동

하지만 프레임워크의 경우에 제어 흐름의 주도권은 프레임워크에 있다

• 프레임워크에서 애플리케이션 코드로 제어 흐름이 이동
• 이를 제어의 역전(IoC, Inversion of Control)이라고 한다

여기서 말하는건 공통 라이브러리와 프레임워크는 제어 주도권의 흐름이 다르기에 다르다는 것을 말함

제어의 역전

https://jhyonhyon.tistory.com/31

제어의 역전과 관련해 이해를 돕기 위해 더 언급하자면 Java는 객체 지향 언어이기에 객체를 위주로 프로그램이 전개


이 때, 단순히 개발자가 정의해 사용하는 Class 뿐만 아니라 구조의 뼈대가 되는(ex, controller, service 등)도 Class이기에 객체로 취급되며 사용되는데 제어의 역전이라는 것은 프로그램에 사용되는 일부 객체들의 생명주기를 프레임워크가 전담하다는 의미


만약 제어가 역전되지 않은 경우 controller, service를 포함한 class로 사용되는 모든 객체들을 사용자가 생성~삭제까지 관리해야되는데 소프트웨어가 운영되면서 controller, service와 같은 객체들이 어디서 호출되고 사용되며 언제 끝마치는지 개발자 입장에서 고려하기 쉽지 않음(프로그램 구조상 A부분에서 또는 B부분에서 가리지 않고 해당 service를 호출할 수도 있기에)
이를 프레임워크가 애너테이션을 이용해 대신 객체의 생산~삭제까지 제어하는 것

IoC 컨테이너

소프트웨어 시스템에 포함되어 있는 모든 클래스 즉, 구성 요소들의 인스턴스를 관리하고 이들 사이의 의존성을 주입하는 일을 담당하는 소프트웨어 구성요소

• 여기서 의존성 주입이란 소프트웨어의 근본적인 어려움 2가지 마지막에 소프트웨어의 의존성을 낮추기 위해 각 소프트웨어들이 직접 다른 소프트웨어의 객체를 관리하는 것이 아닌 중간에서 객체들을 관리해주는 소프트웨어의 행위를 의미

  A, B 소프트웨어가 존재할 때 A에서 B객체를 직접적으로 생성해 사용하면 A는 B의 대한 큰 의존성을 가지기에 B의 수정이 A에 영향을 끼친다
  
  
  이를 극복하는 하나의 방법으로 인터페이스를 이용하는 방법이 있다
  
  인터페이스를 정의하고 B 클래스는 인터페이스를 상속(이 때 인터페이스에 정의되는 메서드는 이 전에 A 객체에서 사용되었던 B객체의 메서드), 이 시점에서 B 클래스를 수정해도 인터페이스로부터 상속 받은 메서드를 수정하지 않는 이상 B 클래스의 수정은 A 클래스의 영향을 끼치지 못한다.
  
  하지만 역시 A 객체에서 B 객체를 선언하고 선언 된 B 객체의 인스턴스로 인터페이스 내부 메서드를 사용하는 것이기에 객체 선언에 대한 의존성은 여전히 존재한다.
  
  
  여기서 의존성을 더 낮추고자 A 내에서 B 객체를 직접 생성하는 것이 아닌 분리한 인터페이스 객체를 생성하고 해당 인터페이스 객체에 B 객체를 주입한다. 이를 IoC 컨테이너라는 소프트웨어가 대신 하며 결국 A 내에서 인터페이스 객체를 생성하고 생성된 객체에 B를 주입하며 A 내에서 B 객체를 생성한 꼴이 된다. 이를 의존성 주입이라고 한다

// 인터페이스 사용 X
public class A {
	private B b = new B();
    
    public A() {
    	b.remove();
    }
}

public class B {
	public remove() {
    
    }
}

// 인터페이스 사용
public class A {
	private B b = new B();
    
    public A() {
    	b.remove();
    }
}

public class B implements C {
	public remove () {}
}

public interface C {
	public remove () {
    
    }
}

// 의존성 주입 사용
public class A {
    private C c;
    
    public A(C c) {
        this.c = c;
    }
}

public class B implements C {

}

public interface C {
	public remove() {
    
    }
}

패턴

소프트웨어 패턴이라는 것은 일종의 가이드라인(guideline)이라고 생각하면 된다

자주 반복되는 상황을 경험을 기준으로 형식화한 것이 패턴(pattern)

• 반복적으로 발생하는 문제들을 설명하고 이 문제들에 대한 해결 방안의 핵심을 설명한 것

템플릿을 작성해 패턴 적용을 자동화하고 이를 다시 컴파일된 형식으로 발전시킨 것이 프레임 워크

소프트웨어의 근본적인 어려움 2가지

복잡성과 변경성
소프트웨어 시스템의 여러 구성 요소가 복잡하게 상호 연결되어 있다는 것과 요구 사항이 변경될 때 프로그램을 수정하기 어렵다는 것

• 시스템이 여러 클래스로 이루어져 있으며 이들 사이의 서로 의존성(dependency)이 강하다는 것
• 여기서 의존성을 간단하게 얘기하면 A, B라는 소프트웨어가 존재할 때 A 소프트웨어의 변경으로 B 소프트웨어가 영향을 받는다면 이는 B가 A에 대해 의존성을 갖는다 라고 할 수 있다
• 인터페이스를 이용해 의존성을 낮추는 즉, 소프트웨어의 결합도를 낮추는 방법 존재
  • 인터페이스가 변경하지 않는 선까지 소프트웨어를 변경하면 낮은 의존성이 존재하는 다른 소프트웨어들은 수정하지 않아도 인터페이스를 계속 사용가능하다

Maven 관련 간단 설명

POM(Project Object Model) : 프로젝트 객체 모델 정보를 담고 있는 파일

• 프로젝트 관리와 빌드에 필요한 환경 설정, 의존성 관리 등의 정보를 포함
• dependency를 이용해 프로젝트가 의존하는 다른 프로젝트에 대한 정보 요소 설정
  • groupId : 의존 프로젝트 그룹 ID
  • artifacId : 의존 프로젝트 아티팩트 ID

일반적으로 메이븐 중앙 레파지토리에서 다운로드 받는다(http://www.repo1.maven.org/maven2)

• 원격 레파지토리에서 다운받은 모듈은 로컬 레파지토리(USER_HOME\m2\repository\groupId\artifactId\version 서브 디렉토리에 저장)