# SOLID
Spring Boot 2일차 (DB연결, MVC패턴)
1. 스프링 컨테이너란(Spring Container) 스프링 컨테이너는 자바 객체의 생명 주기를 관리하며, 생성된 자바 객채들에게 추가적인 기능을 제공하는 역할을 한다. 여기서 말하는 자바 객체를 스프링에서는 빈(Bean)이라고 명칭한다. 개발자는 객체를 생성하고 소멸할 수 있는데, 스프링 컨테이너가 이 역할을 대신해 준다. 즉, 제어의 흐름을 외부에서 관리하는 것이다. 또한, 객체들 간의 의존관계를 스프링 컨테이너가 런타임 과정에서 알아서 만들어 준다. 스프링은 실행시 객체들을 담고있는 Container가 있다. > 컨테이너에 넣을 빈을 설정하는 방법으로는 어노테이션이 있다. 2. MemberController 생성자에 @Autowired 가 있으면 스프링이 연관된 객체를 스프링 컨테이너에 찾아서 넣어준다. 이렇게 객체 의존관계를 외부에서 넣어주는 것을 DI(Dependency Inj
스프링에 대한 기본 지식 및 용어
서비스라는 큰 객체 하나를 만들어 여러 스프링에서 가져다 쓸 수 있게 한다. 스프링 컨테이너란(Spring Container) 스프링 컨테이너는 자바 객체의 생명주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공하는 역할을 한다. 여기서 말하는 자바 객체를 스프링에서는 빈(Bean)이라 고 부른다. 개발자는 객체를 생성하고 소멸할 수 있는데, 스프링 컨테이너가 이 역할을 대신해 준다.즉, 제어의 흐름을 외부(스프링 프레임워크)에서 관리하는 것이다. 또한 객체들간의 의존 관계를 스프링 컨테이너가 런타임 과정에서 알아서 만들어 준다. 스프링은 실행시 객체들을 담고 있는 컨테이너가 있다. MemberController 생성자의 @Autowired가 있으면
객체지향 설계 5원칙 - SOLID
들어가기에 앞서 내가 지향하는 바와 다르게 원칙적인 글을 작성한 이유는 내가 경험한 것이 SOLID를 제대로 이해하고 경험한 것인지에 대한 확신이 없기 때문이다. 이 글을 작성함으로써 SOLID를 제대로 이해하고 경험하기 위해 이 주제를 정리해본다. 1. SRP (Single Responsibility Principle) 단일 책임 원칙 클래스와 메소드는 하나의 역할만 하도록 한다. 이 단일 책임 원칙이 무엇인가. 한마디로 여러가지 의미를 가지는 것을 하나의 클래스로 묶지 말라는 말인거 같다. 예를 들면 우리는 마트에 갈 경우 상품을 구입할 것이다. 이때 상품들은 각자의 특성에 맞게 상품 코너가 분리되어 진열되어있을 것이다. 이렇게 분리한 이유가 무엇일까? 상품은 크게 봤을 때 "구입할 수 있는 물체"이겠지만 좀더 작게 본다면 "먹을 수 있는 상품", "조리할 수 있는 상품" 등 목적에 맞게 분류를 할 수 있다. 이처럼 각 상품의 특징에 맞춰 분리를 해서
리액트에서 커스텀 훅을 통해 관심사 분리하기
관심사 분리 관심사란 무엇일까요? 관심사란 하나의 모듈이 수행하고자 하는 목적을 의미합니다. 하나의 모듈은 한 가지의 관심사를 가지는 것을 좋은 코드라고 부르며, 단일 책임 원칙을 따르고 있다고 말할 수 있습니다. '하나의 모듈이 여러 가지 기능을 할 수 있으면 좋은 게 아닐까?'라는 생각이 듭니다. 그런데 왜 하나의 관심사만 가져야 할까요? 하나의 모듈에서 여러 기능을 가진다면 그 모듈이 수정되어야 할 이유는 여러 가지가 존재하게 됩니다. 이 모듈은 여러 기능들이 얽혀 복잡하며, 하나의 기능을 수정하려면 모듈 전체를 건드려야 합니다. 그리고 이것은 예상치 못한 에러를 발생시킬 수 있습니다. 즉 한 가지 모듈에 여러 가지의 기능을 가지게 되면 유지 보수가 어렵게 됩니다. 그렇기 때문에 관심사를 분리하여 하나의 모듈은 한 가지의 관심사 즉 목적을 가지도록 합니다. 그러면 이 모듈은 수정되어야 할 이유가 한 가지만 존재하게 됩니다. 하드웨어는 물리적인 실체가 있
의존성 역전 원칙을 준수한 HTTP 모듈 구축하기
의존성 역전 원칙 의존성 역전 원칙을 설명하기 전에 먼저 추상화란 구체적인 구현 세부 사항을 숨기고 필요한 부분만 노출시켜 사용자가 내부 동작을 신경 쓰지 않고 기능을 사용할 수 있도록 하는 것입니다. 예를 들어 우리는 console.log의 내부 구현을 생각하지 않고 필요한 기능만 사용합니다. 그렇다면 의존성 역전 원칙은 무엇일까요? 의존성 역전 원칙은 코드의 유연성과 확장성을 높이기 위해 구체적인 구현이 아닌 추상적인 개념 또는 인터페이스에 의존하도록 모듈을 설계하는 것입니다. 클라이언트 코드는 모듈 내부 구현에 직접적으로 의존하지 않고 추상화 또는 인터페이스와 상호 작용하며, 모듈 내부 구현이 변경되더라도 클라이언트 코드에 영향을 미치지 않습니다. 예를 들어 여러 모듈들이 axios라
[Spring] 좋은 객체 지향 설계의 5가지 원칙(SOLID)
SOLID 원칙은 국내에서 클린시리즈의 저자로 유명한 로버트 C 마틴(엉클밥)이 2000년 논문에서 소개했습니다. SOLID 라는 약어는 마이클 패터스에 의해 소개되었습니다. 이 디자인 원칙은 약어 그대로 견고한 원칙입니다. 이 원칙을 지킨다면 우리는 보다 유지 보수가 쉽고, 확장과 변경에 유연한 소프트웨어을 만들 수 있습니다. 결과적으로 애플리케이션의 크기가 커짐에 따라 복잡성을 줄이고 많은 골치 아픈 일들을 줄일 수 있습니다. 아래에서는 스프링에 주로 초점을 맞춰 SOLID를 하나씩 살펴보겠습니다. SOLID - 로버트 마틴 아래의 5가지 개념이 SOLID 원칙입니다. SRP, OCP, LSP, ISP, DIP SRP 단일 책임 원칙 Single Responsibility Principle 한 클래스는 하나의 책임만 가져야 한다. 하지만 이는 실제 개발을 하다보면 분명 모호해지는 상
[초월번역] React에 적용하는 SOLID 원칙
React와 SOLID 원칙에 관한 짧은 글을 읽고 우리말로 옮겨보았습니다. 글의 전개를 역자의 입맛에 맞춰 재구성하였습니다(🤬초월번역주의). 📙 예상 독자 : SOLID 원칙이 무엇인지 알고 싶은 모든 React 개발자 👉원본보기(Mastering React JS SOLID Principles by Kristiyan Velkov) SOLID 원칙은 코드가 느슨하게 결합되어 유지 보수와 확장이 쉽도록 만들어주는 다섯 가지 설계 원칙입니다. 다섯 가지 SOLID 원칙은 아래와 같습니다. [S] - Single-responsibility principle [O] - Open-Closed principle [L] - **Liskov substitution
SOLID 원리에 대해
자바, C#와 같은 객체지향 언어를 다룬다면 한 번은 들어봤을 SOLID 원리에대해서 포스팅 해보고자 한다. 우선 SOLID에 대한 생각을 서술하기 전에 SOLID 원칙이 무엇인지 정리를 해보자면 다음과 같다. SOLID 원칙의 핵심내용 A. SRP (단일책임의 원칙 : Single Responsibility Principle) 정의 작성된 클래스는 하나의 기능만 가지며 클래스가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어야한다는 원칙. 특징 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용이 없어야 함. 책임의 분배로 코드의 가독성, 유지보수성의 향상 해당 원리의 적용을 위해서는 자신이 짜고자하는 객체에 대한 도메인 지식이 필요함. 적용방법 리팩토리 과정을 통해 혼재된 각 책임을 각각의 개별 클래스로 분할한다. 책임만 분리하는 것이 아닌 분리된 두
좋은 객체 지향 설계의 5가지 원칙(SOLID)
1. SRP 단일 책임 원칙 Single responsibility principle 한 클래스는 하나의 책임만 가져야 한다. 하나의 책임이라는 것은 모호하다. 클 수 있고, 작을 수 있다. 문맥과 상황에 따라 다르다. 중요한 것은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 예) UI 변경, 객체의 생성과 사용을 분리 2. OCP 개방-폐쇄 원칙 Open/closed principle 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 다형성을 활용해보자 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현 지금까지 배운 역할과 구현의 분리를 생각해보자 OCP 개방-폐쇄 원칙의 문제점 MemberRepository는 MemoryMemberRepository와 JdbcMemberRepository의 부모이기 때
SOLID 원칙
SOLID란 무엇일까? > 객체지향 설계에 더 좋은 아키텍쳐를 설계하기 위해 지켜야하는 원칙들이며, 5가지로 구성된다. > SRP (단일 책임 원리) OCP (개방폐쇄의 원칙) LSP (리스코브 치환의 법칙) ISP (인터페이스 분리의 법칙) DIP (의존성 역전의 원칙) SOLID 원칙을 지킴으로써 기대할 수 있는 점은, 유지보수가 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 기대할 수 있다! 결합도 > 서로 다른 모듈간의 상호 의존하는 정도 또는 연관된 관계 > 결합도가 높으면 모듈간의 의존하는 정도가 크기 때문에 다른 모듈에 영향 → 오류가 생길 때도 다른 모듈에 영향을 줌 ⇒ 고로, 결합도는 낮을수록 좋다! 응집도 > *모듈 내부의 요소들 간의 기능적 연관성을
[CS-Design Pattern] SOLID와 디자인패턴의 개요
Design Smells 나쁜 디자인을 나타내는 4가지 증상이 있다. Rigidity(경직성) 시스템이 변경되기 쉽지 않다. 하나의 변경을 위해서 다른 것들을 변경해야할 때 경직성이 높다고 판단한다. 경직성이 높아지면 non-critical한 문제가 발생해도, 관리자가 개발자에게 수정을 요청하기 힘들어진다. Fragility(취약성) 취약성이 높다는 것은 시스템의 어느 부분을 수정할 때 관련이 없는 다른 부분에 영향을 준다는 것이다. 수정사항이 관련없는 부분에도 영향을 미쳐 관리하는 비용이 커지게 되며 신뢰성을 잃게 된다. Immobility(부동성) 부동성이 높다는 것은 시스템을 분리하여 재사용을 위한 컴포넌트 활용이 어렵다는 것이다. 주로 개발자가 이전에 구현했던 모듈과 비슷한 기능을 하는 모듈을 만들고 싶을 때 문제를 발견하게 된다. Viscosity(점착성) 개발 환경이 느리고, 효율적이지
SOLID 원칙
SOLID 원칙 > 객체지향에서의 5개의 원칙을 나타냄 소프트웨어 설계와 아키텍처의 품질을 향상시키는 데 도움이 되고, 유지보수가 쉽고, 확장 가능한 시스템을 위한 지침을 제공 1.Single Responsibility Principle(SRP,단일 책임원칙) 클래스는 하나의 책임만 가져야하는 원칙 한 클래스가 너무 많은 일을 하려고 하면, 클래스는 수정이 필요한 경우가 많아지고, 여러 이유로 변경될 가능성이 커진다. 2. Open/Closed Principle (OCP, 개방-폐쇄 원칙) 소프트웨어 구성요소(클래스, 모듈, 함수 등)는 열려 있어야 하지만, 수정에는 닫혀있어야한다. 기존 코드를 변경하지 않고 시스템의 행동을 확장할 수 있어야한다. 3. Liskov Substitution Principle(LSP, 리스코프 치환원칙) 하위 타입은 그것의 상위 타입으로 대체될 수 있어야 한다. 이 원칙이 지켜지지 않으면
[Java] 객체 지향 설계 SOLID 원칙
소프트웨어는 하드웨어와는 다르게 수시로 수정되며 그 길이가 길어질수록 유지 보수는 더욱 힘들어집니다. 그렇기 때문에 코드를 관리함에 있어서 코드를 잘 분류하고 때에 따라서는 특정 모듈을 완전히 교체하더라도 불편함이 없어야 합니다. 이러한 문제점들을 해결하기 위한 최적의 방법이 객체 지향 프로그래밍입니다. 객체 지향 프로그래밍이란 시스템을 구성하는 구성 요소를 객체단위로 구분하여 이 객체들 사이의 상호작용을 중심으로 설계하는 방식을 말합니다. 객체들의 모임으로 이루어져 있기 때문에 변경에 용이하고 유연하며 캡슐화, 상속, 다형성 등 다양한 특징을 가지고 있습니다. 오늘은 이 객체 지향 설계에 있어서 중요한 5가지 원칙에 대해 알아보겠습니다. SOLID SRP : 단일 책임 원칙 OCP : 개방 폐쇄 원칙 LSP : 리스코프 치환 법칙 ISP : 인터페이스 분리 원칙 DIP : 의존성 역전 원칙 SRP:
객체 지향 프로그래밍의 5가지 설계 원칙, SOLID
SOLID란 객체 지향 프로그래밍을 하면서 지켜야 하는 5대 원칙으로, 각각 SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙), LSP(리스코프 치환 원칙), DIP(의존관계 역전 원칙), ISP(인터페이스 분리 원칙)를 의미한다. 1. 단일 책임 원칙(SRP, Single Responsibility Principle) 한 클래스는 하나의 책임만 가져야 한다. 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있음 SRP 단일 책임 원칙을 따르면서 관심사를 분리함 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당 클라이언트 객체는 실행하는 책임만 담당 2. 의존관계 역전 원칙(DIP, Dependency Inversion Principle) 프로그래머는 "구체화가 아닌 추상화에 의존해야 한다"의 원칙을 따르는 방법 새로운 할인 정책
[소프트웨어설계원칙] 객체지향적인 사고 1- OCP
개방 폐쇄 원칙 - OCP(Open Closed Principle) > 변경에는 닫혀있지만 확장에는 열려있다 OCP란 백엔드 개발자라면 코드를 작성할 때 기존의 코드를 변경하지 않으면서, 기능을 원할때 언제든지 추가할 수 있도록 코드를 설계해야한다라는 말을 들어본 적이 있을 것이다. 객체지향의 개발 원리(SOLID) (다른 말로 소프트웨어 설계 기법) 중 하나로 이번 글에서는 OCP에 대해 설명해보고자 한다 > SOLID 설계 원칙은 oop의 4가지 특징(추상화, 상속, 다형성, 캡슐화)와 더불어, 객체 지향 프로그래밍의 단골 면접 질문 중 하나이다. 또한 앞으로 자주 마주칠 디자인 패턴(Design Pattern)들이 SOLID 설계 원칙에 입각해서 만들어진 것이기 때문에 SOLID 설계원칙에 대해서 잘 알아야한다 OCP 는 쉽게 말해 추상화라고 생각하면 편하다 >추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징 추상화와 인터페이스와는 밀접하
SOLID 설계 원칙
서론 클린 아키텍처의 저자인 로버트 C.마틴에 따르면, SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다고 한다. 그래서인지 구글에 SOLID를 검색해보면 다들 객체 지향 원칙이라고 표현한다. 그러나 여기서 객체 혹은 클래스는 객체 지향 언어의 클래스만을 얘기하는 것은 아니다. SOLID에서의 클래스는 단순히 함수와 데이터를 결합한 집합을 일컫는다. 객체 지향 프로그래밍 - 핵심은 의존성 역전에서 다뤘던 것처럼, 객체 지향 언어들은 객체를 지향하는 것을 도와줄 뿐이다.
[북스터디] 자바 코딩 인터뷰 완벽 가이드_ch6객체지향프로그래밍(4)_SOLID
Intro OOD(Object Origined design) SOLID 앞선 포스트들에서 계속 SOLID를 언급했을 정도로 해당 개념은 자바에서 기본 덕목 중에 하나로 다루어진다고 생각한다. why에 대한 고민도 좋지만, 그것을 떠나서 이것이 무엇인지 조차 이해를 못하고 있던 때가 있었는데 이 책을 통해서 이게 무엇이구나가 느껴졌다. 그 이후인 지금은 어째서 이것이 주요한가? 현재 DDD(Domain Driven Development) 개발이 주된 환경에서는 어떤 의미를 가지는가? 등의 고민과 생각이 있다. 하지만 앞서 말한 것처럼 이 개념 자체가 크게 어렵지는 않았다. 정확히는 이 책을 통해서 이해하는게 어렵지는 않았다. 안티패턴과 사용법에 대한 소개가 포함되기 때문이다. 다만, 이러한 안티패턴이라는 것도 개발하는 경우에는 팀 내에서 합의에 따라 정책이 될 수 있다. 즉, 이러한 경우는 S에 어긋난다고 표현되겠다라는 것을 알고 쓰느냐, 모르고 쓰느냐에
[SOLID] 의존 역전 원칙
객체지향의 핵심 원리와 원칙들 DIP, 의존 역전 원칙 > DIP : Dependency Inversoin Principle 고수준 컴포넌트는 저수준 컴포넌트에 의존하지 않아야 한다. 의존 역전 원칙이 깨진 상황과 지켜진 상황 그림처럼 서비스는 레포지토리 클래스에게 의존하고 있습니다. 이것을 어떻게 변경하면 될까요? 고수준 컴포넌트와 저수준 컴포넌트 사이에 고수준 컴포넌트인 Repository(interface)를 만들어서 서비스와 레포지토리들이 인터페이스에 의존하게 변경하였습니다. 화살표를 보듯이 의존 방향이 역전된 것을 확인
[SOLID] 인터페이스 분리 원칙
객체지향의 핵심 원리와 원칙들 ISP, 인터페이스 분리 원칙 > ISP : Interface Segregation Principle 클라이언트별로 세분화된 인터페이스를 만들어야 한다. 인터페이스 분리원칙이 깨진 상황 여기에 Repository가 선언되어 있습니다. 해당 인터페이스를 구현하는 두 개의 클래스를 만들어 보도록 하겠습니다. 해당 코드를 보고 문제를 눈치 채신 분들이 있을 것입니다. UserRepository 클래스에는 createUser메서드와 findUserById 메서드의 구현만 필요하고 ArticleRepository 클래스에는 createArticle 메서드와 findArticleBtId 메서드의 구현만 필요합니다. 하지만 Repository 인터페이스를 구현했기 때문에 필요없는 메서드를 오버라이딩 해야하는 상황이 생긴 것 입니다. 사용해야하는 코드에도 문제가 생깁니다. 사용할 수 없는 메서드가 불필요하게 노출되는 경우가 발생합니다.
[SOLID] 리스코프 치환 원칙
객체지향의 핵심원리와 원칙들 LSP, 리스코프 치환 원칙 > LSP : Liskov Substitution Principle 부모 클래스가 할 수 있는 행동은 자식 클래스도 할 수 있어야 한다. 원래의 정의는 이것이 아니나 직관정의는 이렇다 할 수 있습니다. 리스코프 치환 원칙이 깨진 상황과 그 문제점 부모 클래스가 할 수 있는 걸 자식이 할 수 없는 상황 Child는 Parent를 상속 받아 someMethod를 오버라이딩하고 있습니다. 부모 클래스인 parent 클래스에는 어떤값도 다 받을 수 있지만 자식 클래스인 Chil 클래스는 양수만 받을 수 있습니다. "리스코프 치환 원칙"이 깨진 상황입니다. 이게 무엇이 문제일까요? 이것을 사용하는 Client를 확인해보도록 하겠습니다. Client 입장에서는 parentOrChild에 Parent가 들어있는지 Child가 들어있는지 모릅니다. 이 코드는 당연히 RuntimeException이 발생하