분류 전체보기

디자인 패턴 중 Singleton 패턴에 대해 설명합니다. 개념 오직 하나의 인스턴스 생성만 보장하며 전역 액세스 포인트를 제공하는 클래스 생성 패턴입니다. 공유자원, 메모리 낭비 등을 이유로 인스턴스 개수를 제한하고 싶을 때 사용합니다. 다음과 같은 장점이 있습니다. 전역에서 접근 가능한 공유자원에 하나의 인스턴스만 존재하도록 보장합니다. 전역 변수는 재할당이 가능하여 인스턴스를 저장하기 안전하지 않습니다. 안전하게 전역에서 접근 가능한 액세스 포인트를 제공합니다. 메모리 낭비를 방지합니다. 공유자원 접근을 제한할 수 있습니다. 자세히 살펴보겠습니다. 1. private 속성을 정의합니다. 해당 속성에 인스턴스를 저장하게 됩니다. 2. 클래스 생성자의 접근 제어자를 private로 설정하여 외부에서 접..

디자인 패턴 중 Prototype 패턴에 대해 설명합니다. 개념 이미 존재하는 객체를 복사하는 생성패턴입니다. 외부에서 접근할 수 없는 속성이 존재하거나 추가적인 의존성 없이도 외부에서 객체를 복사하고 싶을 때 사용합니다. 다음과 같은 장점이 있습니다. Single Responsibility Principle: 객체 복사 프로세스를 해당 객체에게 위임하여 비즈니스 로직의 과도한 책임을 분산합니다. Dependency Inversion Principle: 구체적인 구현 객체에 의존하지 않고 인터페이스에 의존하여 객체를 복사할 수 있습니다. 객체 생성 시 복잡하거나 고비용의 구성이 필요한 경우 객체 복사로 대체할 수 있습니다. 외부에서 접근이 어려운 속성도 접근하여 복사합니다. 자세히 살펴보겠습니다. Pro..

디자인 패턴 중 Builder 패턴에 대해 설명합니다. 개념 객체 생성 시 많은 파라미터가 존재하거나 생성과정이 복잡한 객체를 step by step으로 생성하는 생성패턴입니다. 다음과 같은 상황이라면 Builder 패턴을 고려할 수 있습니다. 객체 생성시 세부 사항은 다르지만 유사한 단계를 거치는 상황이 반복된다. 복잡한 세부 사항에 따른 객체의 성격을 보장해야 한다. 생성자 내부 코드가 거대해진다. telescoping constructor가 필요하다. 객체 생성 시 유효하지 않은 파라미터 혹은 파라미터 누락으로 인한 잠재적 에러 가능성 존재한다. 다음과 같은 장점이 있습니다. Single Responsibility Principle: 객체 생성에 대한 책임을 분리하여 비즈니스 로직의 과도한 책임을 ..

디자인 패턴 중 Abstract Factory 패턴에 대해 설명합니다. 개념 Abstract Factory 패턴은 같은 제품군에 속하는 연관된 객체들을 생성하는 생성 패턴입니다. 한마디로 N개의 Factory Method가 모여있는 Factory 클래스입니다. 다음과 같은 장점이 있습니다. 특정 제품군에 해당하는 객체의 생성을 보장할 수 있습니다. Single Responsibility Principle: 객체 생성에 대한 책임을 분리하여 비즈니스 로직의 과도한 책임을 분산합니다. Dependency Inversion Principle: 구체적인 구현 객체에 의존하지 않고 인터페이스에 의존합니다. Open-Closed Principle: 객체 생성자 호출을 비즈니스 로직과 분리하여 객체의 타입이 늘어나도..

디자인 패턴 중 Factory Method 패턴에 대해 설명합니다. 개념 Factory Method 패턴은 슈퍼 클래스에서 비즈니스 로직에 사용되는 객체의 객체 생성 인터페이스를 제공하고, 서브 클래스에서 생성할 객체의 타입을 결정하는 생성 패턴입니다. 다음과 같은 장점이 있습니다. Open-Closed Principle: 객체 생성자 호출을 비즈니스 로직과 분리하여 객체의 타입이 늘어나도 비즈니스 로직이 수정될 필요가 없습니다. 클래스 확장을 통해 해결합니다. Single Responsibility Principle: 객체 생성에 대한 책임을 분리하여 비즈니스 로직의 과도한 책임을 분산합니다. Dependency Inversion Principle: 구체적인 구현 객체에 의존하지 않고 인터페이스에 의존..

이 글은 Python 웹 프레임워크의 내부 동작을 이해하고자 Flask의 일부 기능을 간략하게 설명합니다. 세부적인 구현은 포함되어 있지 않습니다. https://ooknimm.tistory.com/6 글에서 이어집니다. 프로덕션 환경에서는 uwsgi, gunicorn과 같은 WSGI로 HTTP 서버가 실행되고, 이 서버가 웹 애플리케이션을 호출합니다. WSGI 툴은 동시성, 안정성 등 기능들을 제공하기 때문에 필수적으로 사용됩니다. 반면 개발 환경에서는 단독으로 HTTP 서버를 실행하여 pdb 및 IDE를 통해 디버깅할 수 있어야 합니다. app = Flask(__name__) app.run(port=9000) 위와 같이 app을 직접 실행하면 http서버가 listen 되어 9000 포트로 요청하면 ..

https://ooknimm.tistory.com/7 글에서 이어집니다. 전체 코드는 ooknimm/flask-parameter-validator에서 확인할 수 있습니다. 추가해야 하는 기능은 다음과 같습니다. parameter type annotation으로 pydantic model 외에도 python typing 지원 form data 지원 path, query, header를 지원 multiple request parameter를 지원 1편에서는 기초적인 기능만 존재하여 코드가 심플했습니다. 이제 보다 복잡한 요구사항을 수행할 수 있어야 하므로 ParameterValidator와 Dependant만 존재하는 클래스 구조에서 확장하였습니다. 클래스 관계를 직관적으로 확인하기 위해 UML을 그려보겠습..

Flask에는 validation 기능이 내장되어 있지 않으므로 별도의 라이브러리를 사용해야 합니다. flask-request-validator, flask-parameter-validation, flask-inputs, flask-pydantic 등의 오픈소스 라이브러리들이 이미 존재하는데, 이 중에 flask-pydantic이 fastapi의 validation과 비슷한 콘셉트로 가장 만족도가 높은 라이브러리가 될 것 같습니다. 어쨌든 이러한 기능을 직접 만들어 보고 싶었는데, 요 몇 년간 python web framework 중 가장 핫한 fastapi에는 request parameter를 아주 우아하게 validation 하는 기능이 있으니 이를 흉내 내어 만들기로 하였습니다. 전체 코드는 ook..