# ocp
책임 연쇄 패턴
특정한 책임을 가지고 있는 클래스들이 연결되어 있는 구조로 무언가를 처리함요청을 보내는 쪽과 처리하는 쪽을 분리하는 패턴일반적인 코딩으로 패턴을 구성하면 클라이언트가 사용할 핸들러를 알아야만 사용할 수 있는 단점이 존재함→ 책임 연쇄 패턴을 적용하면 클라이언트는 Req
OCP 란
OCP(Open-Closed Principle)는 객체 지향 설계와 프로그래밍의 기본 원리이다. 이 원칙은 "소프트웨어 엔티티(classes, modules, functions 등)는 확장을 위해 개방되어야 하지만 수정을 위해 폐쇄되어야 한다."즉, OCP의 목표는 기

23.02.03
우아한형제들의 기술블로그를 읽으면서 정리한 내용이다.핵심 키워드객체타입관계오퍼레이션이 4가지로 생각해 보았다.객체를 나눠서 생각해보는 과정이 중요해 보인다.블로그에서 예시로 커피점에서 커피를 사는 과정을 분석해본 예가 있다.여기서 느낀점은 생각보다 세분화된 객체와 타입

[배포] Cloud Compute 로 배포하기
Java 설치 (11 or 17 , JRE JDK)Java 11Java 17https://sunshower99.tistory.com/22 참고 자료 , yum 을 안쓰는 방법 Cloud Computing 설치 AWS AzureNaverclovaGCPAlibab

SOLID 원칙 (객체 지향 설계)
한 클래스는 하나의 책임만 가져야 한다.위에서 말하는 책임 이라는 단어는 기능 이라고 해석이 가능하다.예를 들면 나라는 객체가 존재 한다면 아들,직장인,남자친구 등 다양한 소속 및 위치에서 책임을 가진다.그러한 책임들을 하나의 객체에 각자 매칭하여 변경이 있을 떄 파급
좋은객체지향의 원리
SRP:단일 책임 원칙OCP:개방-폐쇄 원칙LSP:리스코프 치환 원칙ISP:인터페이스 분리 원칙DIP:의존관계 역전 원칙한 클래스는 하나의 책임만 가져야 한다하나으ㅢ 책임이라는 것은 모호하다\-클 수 있고, 작을 수 있다.\-문맥과 상황에 따라 다르다중요한 기준은 변경
[About Spring] 스프링의 핵심 원리
스프링은 어떤 특정한 하나의 기술이 아닌, 여러가지 기술의 집합체이다. 그 기술의 형태는 다음과 같다.스프링 프레임워크스프링의 가장 핵심 기술인 스프링 프레임워크스프링 부트여러기술을 편리하게 사용할 수 있도록 도움을 주는 스프링 부트스프링 데이터CRUD를 편리하게 사용

Open-Closed Principle(OCP)
정의 확장에는 열려있고 변화에는 닫혀있다는 뜻. 다시 말하면, 변경사항에 대해 기존 코드는 변경하지 않고(Closed) 기능을 추가(Open)하는 것을 의미한다. 직접적으로 두 클래스 간에 직접적으로 의존하게 되면 기존 코드에 변경이 생길 수 밖에 없다. 구현체에

[개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴] 설계 원칙: SOLID
객체 지향적으로 설계하는데 기본이 되는 설계 원칙인 SOLID에 대해 알아보자.

개방 폐쇄 원칙(OCP)
Bertrand Meyer은 1988년에 그의 논문에서 개방 폐쇄 원칙을 아래와 같이 설명했다."Software entities (classes, modules, functions, etc.) should be open for extension, but closed f

[Design Pattern] 팩토리 메소드 패턴
📚 팩토리 메소드 패턴 팩토리 메소드 패턴은 특정 객체의 인스턴스를 생성하는 "책임"를 추상적인 Interface로 감싸는 패턴을 의미한다. 이 뜻을 더 쉽게 말하면 다음과 같다 구체적으로 어떤 인스턴스가 생성될지는 Concre

[기본기] 7-6. 의존관계 자동 주입을 하는 방법들, 옵션 처리
본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.우리가 이때까지 의존관계 주입하는 방법으로 지금까지는 우리가 생성자 주입을 사용을 했었는데 사실은 이거 하나만 있는 것은 아니고 다른 여러가지 방법이 있다고 한다.생성자 주입수정자(Setter) 주입필드

[기본기] 7-1. SingleTon & Stateful의 문제
본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.SingleTon에 대해서 설명을 하기 이전 우선 이것이 왜 생겨나게됬는지에 대해서 한 번 알아보고 가보자. 다음과 같은 그림을 한 번 볼까? 지금까지처럼 이제 웹 어플리케이션 개발을 하게 될 경우 이제

[기본기] 5-4. 관심사의 분리
본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.이전 글에서 마지막에 이제 OCP, DIP를 지키기 위하여서 구현체를 의존하지 않게 하기 위하여서위의 주석 코드를 아래처럼 바꿔서 진행을 해야 한다고 하였다. 그러나 이렇게 진행할 경우 구현체가 없이 코
객체지향 설계 원칙 SOLID
Single responsibility principle한 클래스는 하나의 책임만 가져야한다.클래스를 변경하는 이유는 단 하나여야한다.변경에 따른 파급효과가 적다Open/closed principle확장에는 열려있으나, 변경에는 닫혀있어야한다.다형성을 활용Liskov

[기본기] 5-3. 좋은 객체 지향 설계를 하기 위하여
본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.할인에 대한 정책을 바꿨다. 기존에는 1000원 고정 할인이었지만 이제는 비율에 따라 할인을 하여주기로 하였다. 그치만... 이게 벌써 변경이 일어난걸 보니 좋은 객체 지향설계인건 벌써 떠나간거 같다.