개발블로그

개념 필요성프로그램을 만들다 보면 어떤 객체는 여러 개 만들어질 필요가 없거나, 여러 개 만들어지면 문제가 되는 경우가 있다. EX] 애플리케이션 설정 정보를 관리하는 객체config1 = AppConfig()config2 = AppConfig() 만약 설정 객체가 여러 개 만들어지고, 각각 다른 상태를 가지게 된다면 프로그램 안에서 사용하는 설정값이 달라질 수 있음=> 이런 상황에서는 어느 설정값이 실제 기준인지 헷갈릴 수 있음 또 데이터베이스 연결 관리자, 로거, 캐시 관리자처럼 애플리케이션 전체에서 하나의 기준으로 관리하는 객체도 있다.이런 객체가 불필요하게 여러 개 만들어지면 상태 관리가 어려워지거나 자원이 낭비될 수 있음 의미특정 클래스의 인스턴스를 하나만 생성하고, 그 인스턴스에 접근할 수 ..

개념 필요성프로그램을 만들다 보면 기존 기능은 유지하면서, 그 앞뒤로 부가 기능을 추가해야 하는 경우가 있다. EX] 결제 기능payment.pay(10000)처음에는 결제만 처리하면 충분할 수 있다. 하지만 시간이 지나면 결제 전후로 여러 기능이 추가될 수 있다. ex) 로깅, 권한 확인, 캐싱, 알림 기능들이 기존 결제 클래스 안에 계속 추가되면, 클래스의 책임이 점점 커짐.class PaymentService: def pay(self, amount): check_permission() write_log("결제 시작") result = process_payment(amount) send_notification() write_log("..

개념 필요성프로그램을 만들다 보면 이미 존재하는 코드와 새로 사용해야 하는 코드의 형식이 맞지 않는 경우가 있음.=> 기존 코드가 기대하는 방식과 새로 연결할 객체의 방식이 다를 때, 중간에서 맞춰줄 수 없을까? ex)결제 객체가 pay(amount)라는 메서드를 제공payment.pay(10000) 그런데 새로 연동해야 하는 외부 결제 API는 다른 이름과 다른 형식의 메서드를 제공 할 수 있음external_payment.request_payment(price=10000) 기능은 비슷함 (둘 다 결제를 처리)BUT 사용하는 방식이 다르기 때문에 기존 코드에서는 바로 사용할 수 없음. 해결방법 => 외부 API를 기존 코드 형식에 맞게 감싸기 의미어댑터 패턴은 서로 맞지 않는 인터페이스를 중간에서 ..

개념 필요성프로그램을 만들다 보면 어떤 객체의 상태 변화가 여러 기능에 영향을 주는 경우가 있다. EX) 주문 상태가 결제완료로 바뀌었다고 할 때, 단순히 주문 상태만 바꾸면 끝나지 않음.=> 상태 변화에 따라 여러 후속 작업이 필요할 수 있음ex) 알림발송, 재고차감, 배송 준비, 포인트 적립...def complete_order(order): order.status = "paid" send_notification(order) decrease_stock(order) prepare_delivery(order) add_point(order) # 상태 변화에 반응해야 하는 기능이 계속 늘어나면, 주문 로직은 점점 많은 일을 알게 됨# ex) 나중에 쿠폰 사용 처리, 리뷰 요청..

개념 필요성프로그램을 만들다 보면 객체를 생성하는 조건이 복잡해지는 경우가 있음. ex) 결제 방식에 따라 서로 다른 결제 객체를 만들어야 함if payment_type == "card": payment = CardPayment()elif payment_type == "kakao": payment = KakaoPayPayment()elif payment_type == "point": payment = PointPayment() 처음에는 이 정도 조건문도 크게 문제되지 않음. 하지만 결제 방식이 계속 추가되거나, 객체 생성에 필요한 설정이 많아지면 생성 코드가 점점 복잡해짐, 문제는 이런 생성 코드가 여러 곳에 흩어질 수 있다. => 새로운 결제 방식이 추가될 때 여러 코드를 함께 수정해야..

개념필요성프로그램을 만들다 보면 같은 흐름 안에서 일부 동작만 달라지는 경우가 있음. 의미실행할 알고리즘이나 정책을 별도의 객체로 분리하고, 실행 시점에 필요한 전략을 선택해서 사용하는 패턴 ex) 할인 예시에서의 전략정액할인 - 일정 금액을 할인하는 방식정률 할인 - 주문 금액의 일정 비율을 할인하는 방식VIP 할인 - 회원 등급에 따라 더 높은 비율을 할인하는 방식쿠폰 할인 - 쿠폰 조건에 따라 할인 금액을 계산하는 방식 핵심 구조구성 요소역할예시Context전략을 사용하는 객체주문 가격 계산기Strategy공통으로 따라야 할 전략의 형태할인 정책Concrete Strategy실제 동작을 구현한 구체적인 전략정액 할인, 정률 할인, VIP 할인 예시 ex) 주문금액에 할인을 적용전체흐름 : 주문..

개념 개념소프트웨어 설계에서 자주 반복되는 문제와 그 해결 방식을 정리한 것 단, 디자인 패턴은 완성된 코드는 아니다. 패턴을 그대로 복사해서 붙여 넣는 코드 조각이 아니라, 특정 상황에서 코드를 어떤 구조로 나눌지에 대한 설계 아이디어에 가까움 주로 반복되는 설계 문제반복되는 설계 문제예시 상황연결되는 패턴여러 방식 중 하나를 선택해야 함카드 결제, 포인트 결제, 쿠폰 결제 중 하나를 선택전략 패턴객체 생성 조건이 복잡함회원 등급에 따라 다른 할인 정책 객체 생성팩토리 패턴하나만 존재해야 하는 객체가 있음설정 관리 객체, 애플리케이션 전역 상태 관리싱글톤 패턴서로 맞지 않는 인터페이스를 연결해야 함외부 결제 API 응답 형식을 내부 결제 코드에 맞춰 사용어댑터 패턴상태 변화가 여러 곳에 전달되어야 함주..

왜 SOLID 원칙이 필요할까? 객체지향으로 코드를 작성한다고 해서 자동으로 좋은 설계가 되는 것은 아님. 클래스를 나누었지만 하나의 클래스가 너무 많은 일을 할 수 있고, 기능을 하나 추가할 때마다 기존 코드를 계속 수정해야 할 수도 있다. 또한 상속을 사용했지만 자식 클래스가 부모 클래스처럼 동작하지 않아 예상치 못한 오류가 생길 수도 있다. 즉, 객체지향의 핵심은 단순히 클래스를 사용하는 것이 아니라 변경에 강하고 이해하기 쉬운 구조를 만드는 것 5가지 기준 원칙이름핵심 질문SRP단일 책임 원칙이 클래스가 바뀌는 이유가 하나인가?OCP개방-폐쇄 원칙기능 추가 때 기존 코드를 계속 수정해야 하는가?LSP리스코프 치환 원칙자식 객체를 부모 객체처럼 사용해도 문제가 없는가?ISP인터페이스 분리 원칙사..

코드는 왜 점점 관리하기 어려워질까? 처음 프로그램을 만들 때는 코드가 단순하다. 변수 몇 개를 만들고, 함수를 호출하고, 조건문과 반복문으로 흐름을 제어하면 된다. 하지만 기능이 조금씩 추가되면 문제가 생긴다. 문제는 데이터와 규칙이 코드 곳곳에 흩어지기 시직함특정 데이터가 어디서 변경되는지 찾기 어렵다같은 규칙이 여러 곳에 중복된다한 곳을 수정했는데 예상하지 못한 다른 기능이 깨진다새로운 기능을 추가할수록 기존 코드를 건드리는 일이 많아진다결국 코드가 어려워지는 이유는 단순히 줄 수가 많아져서가 아니라데이터와 그 데이터를 다루는 규칙이 흩어지고, 변경의 영향 범위를 예측하기 어려워지기 때문 객체지향은 이 문제를 어떻게 바라볼까? 관련된 데이터와 동작을 하나의 객체 안에 모으면 어떨까? 관련된 데..

REST란? 개념Representational State Transfer분산된 시스템에서 구성 요소들이 일정한 방식으로 통신하도록 설계하기 위한 Architectural Style 특정 Protocol이나 Framework, Library를 의미하는것이 아니라 시스템의 구성 요소가 어떤 역할을 가지고 어떤 제약 아래에서 통신할지를 정의하는 설계 방식 Resource를 중심으로 통신Resource = 시스템에서 식별할 수 있는 대상 ex) 쇼핑몰의 Resource => 상품,사용자, 주문, 리뷰 REST에서는 Client-Sever가 Resource 자체를 직접 주고받는 것이 아니라, Resource를 표현한 Representation을 주고받음 ex){ "id": 10, "name": "Key..