생성자 주입 생성자를 통해서 의존관계를 주입 받는 방식 생성자 호출 시점에서 딱 한번만 호출되는 것이 보장되어 불변이나 필수 의존관계에 사용한다. 클래스에 생성자가 한개라면 를 생략해도 자동주입이 된다. 수정자 주입(setter) 수정자 메소드를 통해서 의존관계를 주입하는 방식 선택이나 변경 가능성이 있는 의존관계에 주로 사용한다. 필드 주입 필드에 바로 주입하는 방법으로 외부에서 변경이 불가능하다. 잘 사용하지 않지만 테스트 코드에서 종종 사용하기도 한다. 생성자 주입을 사용해야 하는 이유 객체의 불변성을 확보해주기 때문이다. 실제로 개발을 하다보면 의존관계의 변경이 필요한 상황은 거의 없으므로 수정의 가능성을 열어둘 필요가 없다. 그러므로 생성자 주입을 통해서 변경의 가능성을 없애고 불변성을 보장하는 것이 좋다고 생각한다. 생성자 주입 수정자 주입(setter) 필드 주입 생성자 주입을 사용해야 하는 이유

POST 요청된 리소스 생성 GET 요청 URI의 데이터를 조회하여 응답 PATCH 요청된 리소스 부분 수정 PUT 요청된 리소스 전체 수정 DELETE 요청된 리소스 삭제 HEAD GET 메소드와 동일하게 동작하지만 응답 바디는 포함하지 않음 CONNECT 대상 리소스로 식별된 서버에 대한 터널을 설정 OPTIONS 웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용 TRACE 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 POST GET PATCH PUT DELETE HEAD CONNECT OPTIONS TRACE

REST? REST는 Representational State Transfer의 약자로, 자원을 정의하고 자원에 대한 주소를 지정하는 방법의 모음 REST 제약조건 REST의 제약조건을 제대로 지키면서 아키텍처를 만드는것을 RESTful이라고 한다. 클라이언트 - 서버 구조 서버는 API제공, 클라이언트는 세션, 로그인정보등을 직접 관리하는 구조로 각각의 역할이 확실하게 구분됨 개발해야할 내용이 명확해지고 서로간의 의존성이 줄어들게 됨 무상태성 서버는 클라이언트의 상태 정보를 저장하지 않음 캐시 가능 REST는 HTTP의 웹표준을 그대로 사용하기 때문에, HTTP가 가진 캐싱 기능 적용 가능 계층화 시스템 REST 서버는 다중 계층으로 구성될 수 있음 자체 표현 구조 REST API 메시지만 보고 쉽게 이해할 수 있음 유니폼 인터페이스(uniform interface) URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일 REST API의 구…

개발자가 작성한 클래스를 빈으로 등록하기 위한 어노테이션이다. , , , , 이 붙은 클래스를 찾아서 컨텍스트에 빈으로 등록해주는 어노테이션이다. 개발자가 직접 제어가 불가능한 외부 라이브러리등을 빈으로 만들려할 때 사용되는 어노테이션이다. 외부 라이브러리 객체를 반환하는 메소드를 만들고 @Bean 어노테이션을 사용하면 된다. 해당 클래스가 컨트롤러 역할을 한다는 것을 알려준다. 해당 클래스가 비즈니스 로직을 수행한다는 것을 의미한다. 해당 클래스가 DB에 접근하는 메소드를 포함 한다는 것을 알려준다. 요청 URI와 어노테이션에 작성된 value 값이 일치하면 해당 클래스가 실행된다. HTTP 요청 바디를 자바 객체로 매핑해준다. 자바 객체를 HTTP 응답 바디로 매핑해준다. 필드, setter, 생성자에서 사용하며, 빈을 주입해준다.

스프링은 각 클래스를 빈으로 등록하기 위해서 라는 어노테이션을 제공하지만, 실제 개발을 할 때는 보다 , , 를 더 많이 사용하게 되는 것 같다. 왜 를 사용하지 않고 의 하위개념인 어노테이션을 따로 제공하는걸까? 답을 찾기 위해 스프링 공식문서를 살펴봤더니 아래와 같은 문장이 있었다. Therefore, you can annotate your component classes with @Component, but, by annotating them with @Repository, @Service, or @Controller instead, your classes are more properly suited for processing by tools or associating with aspects. 를 사용하여 클래스에 주석을 달 수 있지만 , , 을 사용하는게 도구를 활용한 처리나 다양한 측면과의 연관성을 더 적절하게 갖출 수 있다고 나와있다. 너무 번역말투라 느낌가는대로 받아들…

DTO(Data Transfer Object) 데이터 이동 객체라는 의미를 갖는다. 계층 간 데이터를 주고 받을 때 사용하며 로직을 갖지않는 순수한 데이터 객체이다. 데이터를 어떤 방식으로 초기화하느냐에 따라서 가변객체/불변객체로 구분된다. 가변객체 : setter로 데이터를 초기화하는 경우 불변객체 : 생성자로 데이터를 초기화 하는 경우 VO(Value Object) 값 자체를 표현하는 객체 객체의 불변성을 보장하고 값을 읽는 것만 가능하다. 서로 다른 이름을 가진 VO더라도 모든 속성 값이 같다면 두 인스턴스는 같은 객체라고 할 수 있다. 이를 보장하기 위해서는 Object 클래스의 와 를 오버라이딩 해야한다. Entity 데이터베이스 테이블과 1:1로 매핑되는 클래스로 DB 테이블 내의 컬럼만 필드로 가져야 한다. Entity를 기준으로 테이블이 생성되고 스키마가 변경되기 때문에 요청이나 응답값을 전달하는 클래스로 사용하면 안된다. 비교하기 DTO VO Entity 레이어 …

오늘의 과제는 도메인 주도 설계와 SQL 중심 설계에 대해서 공부하고 비교해보는 것! DDD(Domain-Driven Design) 개념 도메인 소프트웨어로 해결하고자하는 문제의 영역 도메인 모델 특정 도메인을 개념적으로 표현한 것 도메인 모델을 사용하면 동일한 모습으로 도메인을 이해하고, 지식을 공유하는데 도움이 된다. 도메인 주도 설계 도메인 패턴을 중심에 놓고 설계하는 방식 특징 데이터 중심의 접근법이 아니라 도메인의 모델과 로직에 집중한다. 보편적인 언어를 사용한다. 분석 모델과 설계, 코드가 모두 다른 구조가 아닌 도메인 모델부터 코드까지 항상 움직이는 구조의 모델을 지향한다. SQL 중심 설계 정의 데이터베이스의 설계에서 시작되는 소프트웨어 개발 방법론중 하나 특징 데이터베이스 구조와 데이터 흐름을 중심으로 시스템을 설계하고 개발 프로세스를 진행한다. 차이점 DDD 설계 SQL 중심 설계 도메인 중심 설계 데이터베이스 중심 설계 도메인의 문제 영역을 중심으로 설계 데이터…

제어의 역전과 의존관계 주입.. 영어로 보면 더 무슨 뜻인지 모르겠다. Inversion of Control, Dependency Injection 🙄 느에..? 두 용어에 대한 정의가 한번에 머리속에 들어오지는 않는다. 하지만 자바로 된 프로그램에 스프링을 적용하는 법을 배우다보면 어느새 은근슬쩍 내 머리에 들어와 있는 경험을 할 수 있다! 오늘은 강의를 들으면서 몸소 체험했던 IoC와 DI에 대해서 적어보려고 한다.(틀릴 수 있음 주의!🚨) 문제점 IoC와 DI가 적용되지 않은 프로그램은 아래와 같이 클라이언트 코드가 스스로 서버 객체를 생성하고 연결하고 실행했다. 수정이 필요할 경우 구현 객체를 클라이언트 코드에서 직접 수정해야 한다. 이럴경우 객체지향적인 설계원칙을 위반하게 된다. 그래서 클라이언트가 구현 객체와 상관없이 인터페이스에만 의존하도록 변경하여야 한다. 위 코드로 변경하면 객체지향적으로 설계한 것이지만 구현 객체가 없기 때문에 실행이 되지 않는다. 결국 구현 객…

2일차 과제를 제출하면서 강사님께 질문을 드렸다. 당연히 @Override가 붙어져 있어야 한다고 생각했기 때문이다. 돌아온 대답은..! 다 계획이 있으신 거였다😎 그래서 3일차의 과제는~! 오버라이딩이 뭔가요? 여러분들이 생각하실 때, 오버라이딩을 구현하려면 @Override를 꼭 적어야 하나요? 1. 오버라이딩이란? 하위 클래스가 상위 클래스의 메소드를 재정의해서 사용하는 것 2. 오버라이딩을 구현하려면 @Override를 꼭 적어야 하나요? 어노테이션은 필수는 아니지만, 작성을 해주면 컴파일 단계에서 개발자의 실수를 방지할 수 있다. Parent 클래스의 hello 메소드를 재정의해서 사용하고 싶은 경우(오버라이딩) 매개변수, 리턴타입, 메소드명을 상위 클래스의 메소드와 동일하게 작성한다면 없이도 오버라이딩된 메소드라고 인식이 된다. 하지만 위 코드는 개발자의 실수로 매개변수가 다르게 작성되어서 오버라이딩하고 싶은 개발자의 의도와 다르게 동작한다! 이때 를 붙여준…

오늘도 역시나 내 머리속에 있고 나 혼자서는 응~그치그치~ 하면서 이해할 수 있는 내용이지만, 남에게 설명하려면 입이 안 떨어지고 어버버하게되는 그런 과제였다. 그 과제가 뭐냐구요..? 인터페이스가 가지고 있는 객체 지향의 특징에는 어떤 것이 있는지 그렇게 생각하는 이유는 무엇인지 자! 오늘도 머리에 있는걸 열심히 끄집어 내보자🤯 내 머릿속에 있는 생각 객체지향의 특징에는 캡슐화, 추상화, 다형성, 상속이 있다. 인터페이스는 이 속성들 4가지를 모두 가지고 있다고 생각한다. 캡슐화 인터페이스는 상수와 추상메소드만을 가질 수 있다. 추상메소드만을 가질 수 있다는 것은 메소드의 구현을 클래스에게 위임하였다는 뜻으로, 각 기능의 정의와 구현을 분리하여 캡슐화를 한 것이다. 추상화 인터페이스는 공통된 기능을 추출해서 정의한 것이기 때문에 추상화 되었다. 다형성 인터페이스를 구현한 클래스라면, 인스턴스의 참조변수 타입을 인터페이스로 할 수있다. 상속 인터페이스도 인터페이스를 상속받을 수…

어제 첫 라이브 세션을 시작으로 스진초 과정이 시작되었다! 프로그래밍은 외우는 것이 아니라 생각하고 이해하면서 해야한다고 말씀해주셨는데, 첫 과제부터 스진초의 정체성이 잘 나타나는거 같다. 내가 생각하는 캡슐화, 추상화, 다형성, 상속성 최근에 자바의 정석을 읽으면서 내용정리를 했기때문에 과제를 보고 ‘ㅎ..할만하군..’ 이라고 생각했다. 하지만 지금 이 글을 적는 이 순간 머리속에 있는 꺼내려고 하니까 쉽지않다. 그래도 최대한 적어봐야지..! 캡슐화 데이터의 무분별한 변경을 방지하기 위해서 접근제어자를 private으로 선언하여 외부의 접근을 막는 방식 추상화 추상 클래스를 상속받은 하위 클래스에게 메소드의 작성을 위임하는 방식 다형성 상위 클래스의 타입으로 하위 클래스의 인스턴스를 참조할 수 있도록 하는 방식 상속 공통된 속성을 모아놓은 클래스(상위 클래스)를 확장하여 새로운 클래스(하위 클래스)를 정의하는 방식 구글링으로 알아낸 캡슐화, 추상화, 다형성, 상속성 캡슐화 변수…