라이브러리와 프레임워크, 디자인패턴 _ 싱글톤패턴 / 의존성 주입 패턴

# 라이브러리와 프레임워크

 

*라이브러리 : 재사용 가능한 코드의 모음. 개발자는 필요할 때 가져와서 사용 가능. 

특정 기능이나 작업을 수행하는 함수, 클래스, 메서드 등의 코드 집합.

독립적으로 실행되지 않으며 다른 프로그램이나 프로잭트에서 호출하여 사용됨. 

ex) NumPy, jQuery, React Router

 

*프레임워크 : 소프트웨어 개발을 위한 구조나 틀을 제공하는 도구.

애플리케이션의 전체 구조를 결정하고 개발 방법을 지정함.

개발자에게 제어 흐름을 주도하며 개발자는 프레임워크의 규칙과 구조에 따라 코드를 작성.

일반적으로 특정 도메인이나 애플리케이션 유형에 특화되어있으며 해당 도메인의 모범사례와 디자인 패턴을 따름.

ex)Django, Ruby on Rails, Angular

 

*라이브러리와 프레임워크의 차이?

- 1. 제어 흐름 : 라이브러리는 개발자가 호출하여 사용하고 제어함, 프레임워크는 개발자가 프레임워크의 규칙과 구조에 따라 코드를 작성하고 프레임워크가 제어흐름을 주도함.

- 2. 의존성 : 라이브러리는 개별적으로 사용될 수 있고, 필요한 기능만 선택적으로 가져와서 사용 가능, 프레임 워크는 일반적으로 전체 구조와 기능이 상호 의존적이며, 프레임워크의 규칙을 따라야함.

- 3. 확장성 : 라이브러리는 개발자가 필요에 따라 쉽게 추가하거나 제거 가능, 프레임워크는 미리 정의된 구조에 따라 개발되어 확장하기가 상대적으로 더 어려울 수 있음.

- 4. 제어권 : 라이브러리는 개발자에게 더 많은 제어원을주지만, 프레임워크는 개발자의 코드를 프레임워크에 맞춰 작성 해야함. 

 

=> 라이브러리는 개발자가 필요한 기능을 선택하여 사용할 수 있는 독립적인 코드 모음 

=> 프레임 워크는 애플리케이션의 전체 구조와 제어 흐름을 정의하는 도구

 

# 디자인 패턴

 

*디자인 패턴 : 소프트웨어 개발에서 자주 나타나는 문제들을 해결하기 위한 일반적인 해결책을 제공하는 

"형식화" 된 설계 방법. 디자인 패턴은 경험과 최적의 설계원칙을 토대로 개발자들 사이에서 공유되고 사용되며

재사용 가능한 코드 구조를 제공하여 소프트웨어의 유연성, 확장성 및 유지보수성을 향상 시킴.

 

*디자인 패턴의 카테고리

1. 생성 패턴 : 객체 생성과 관련된 패턴, 객체를 생성하는 방법과 객체간의 의존성을 줄이는 방법에 중점을 두고있음.

ex)싱글톤 패턴, 팩토리 패턴, 추상 팩토리 패턴

 

2. 구조 패턴 : 클래스와 객체를 조합하여 더 큰 구조를 형성하는 방법에 중점을 두고있음. 

ex)어댑터 패턴, 데코레이터 패턴, 컴포지트 패턴

 

3. 행위 패턴 : 객체간의 상호작용과 책임 분배에 관련된 패턴, 객체간의 효율적인 소통과 협력을 위한 방법에 중점을 두고있음. 

ex)옵저버 패턴, 전략 패턴, 커맨드 패턴

 

*싱글톤 패턴 : 디자인 패턴의 생성 패턴 중 하나. 어떤 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 패턴.

전역적으로 접근 가능한 하나의 인스턴스를 유지하고, 해당 인스턴스에 대한 중복 생성을 방지하여 일관성과 효율성을 보장함

 

1. private 생성자 : 클래스 외부에서 인스턴스 생성을 막기위해 생성자를 private로 선언. 클래스 외부에서 직접적으로 인스턴스 생성 불가

2. 정적 메서드 : 클래스 내부에서 자체적으로 유일한 인스턴스를 생성하고 반환하는 정적 메서드를 제공, 이 메서드는 항상 동일한 인스턴스를 반환하며, 처음호출될때에만 인스턴스를 생성하고 이후 생성된 인스턴스를 반환함.

3. 정적 변수 : 유일한 인스턴스를 참조하는 정적 변수를 선언. 이 변수는 클래스 외부에서 접근 가능한 경우 해당 인스턴스에 접근할 수 있음. 

 

*싱글톤 패턴의 장점 : 하나의 인스턴스만 유지하여 자원의 공유와 일관성을 유지할 수 있음.

인스턴스를 필요한 시점에 생성하여 효율적인 리소스 관리 가능

 

*싱글톤 패턴의 단점 : 전역적인 상태를 유지함으로 상태 관리가 복잡해질 수 있음.

멀티스레드 환경에서 동시에 접근하는 경우 동기화 문제를 고려해야함.

의존성을 강화시킬 수 있고 테스트가 어려울 수 있음.

 

*싱글톤 패턴의 단점(유연성, 테스트 용이성, 결합도 감소)을 보완하기 위한 의존성 주입(DI) 패턴

- 클래스 간의 의존 관계를 하드코딩 하는 대신 의존성을 외부에서 주입하여 유연하고 테스트 가능한 코드를 작성 할 수 있게 도움.

 

1. 의존성 : 클래스가 다른 클래스나 인터페이스에 의존하는 경우 해당 클래스나 인터페이스를 의존성으로 간주함.

일반적으로 클래스의 생성자 매개변수, 메서드 매개변수, 속성등을 통해 표현

2. 주입 : 의존성을 외부에서 제공하여 클래스 내부로 주입하는 것을 의미함. 의존성 주입은 클래스가 직접 의존성을 생성하거나 참조하지 않고 외부에서 제공된 의존성을 사용하여 클래스의 동작을 수행함.

3. 주입 방식 : 생성자 주입, 메서드 주입, 속성 주입 등이 있음. 가장 일반적인 방법은 생성자 주입으로 클래스의 생성자를 통해 의존성을 주입함.

 

=> 싱글톤 패턴의 단점을 보완할 수 있음!

1. 유연성 : 의존성을 외부에서 주입함으로 의존성을 변경하거나 대체하기 쉬움. 소프트웨어의 유연성과 확장성 향상

2. 테스트 용이성 : 의존성을 모의 객체로 대체하여 유닛 테스트를 수행 할 수 있음. 

3. 결합도 감소 : 클래스 간의 강한 결합도를 줄여줌

 

*싱글톤 패턴의 예시(C#)

public class Singleton
{
    //private 생성자를 추가하여 외부에서의 직접적인 인스턴스 생성을 방지
    private static Singleton _instance;

    private Singleton() { }

    public static Singleton Instance
    {
        get
        {
        	//인스턴스가 null인 경우에만 인스턴스를 생성하여 할당
            if (_instance == null)
            {
                _instance = new Singleton();
            }
            return _instance;
        }
    }

    public void DoSomething()
    {
        Console.WriteLine("Doing something...");
    }
}

*의존성 주입 패턴의 예시(C#)

public interface IService
{
    void DoSomething();
}

public class ConcreteService : IService
{
    public void DoSomething()
    {
        Console.WriteLine("Doing something...");
    }
}

public class Client
{
    private readonly IService _service;

	//생성자 주입(Constructor Injection)을 통해 의존성을 주입
    public Client(IService service)
    {
        _service = service;
    }

    public void Run()
    {
        _service.DoSomething();
    }
}

 

*싱글톤 패턴과 의존성 주입 패턴의 사용

1. 싱글톤 패턴 : 싱글톤 패턴은 하나의 인스턴스를 고유해아하는 상황에서 사용, 전역적으로 접근 가능한 인스턴스가 필요하거나 리소스 공유 또는 로깅 용도로 사용 할 수 있음.

 

2. 의존성 패턴 : 클래스 간의 결합도를 낮추고 테스트 용이성을 확보하고자 할때 쓰임. 클래스 의존성을 외부에서 주입받아 유연한 코드를 작성하고 의존성 관리를 자동화 하는데 유용.