개발블로그

개념 필요성프로그램을 만들다 보면 어떤 객체의 상태 변화가 여러 기능에 영향을 주는 경우가 있다. 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() 처음에는 이 정도 조건문도 크게 문제되지 않음. 하지만 결제 방식이 계속 추가되거나, 객체 생성에 필요한 설정이 많아지면 생성 코드가 점점 복잡해짐, 문제는 이런 생성 코드가 여러 곳에 흩어질 수 있다. => 새로운 결제 방식이 추가될 때 여러 코드를 함께 수정해야..

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

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