지금까지 프로젝트를 진행하면서, 나만의 컨벤션에 대해 고민해 보지 않은 것 같습니다.. 그렇기 때문에 항상 구글링 또는 다른 사람들의 코드를 보며 맞춰서 작성한 것 같아요

공부를 하면 할수록, 내 주장이 들어간 코드를 작성하고 싶은 욕구가 뿜뿜했습니다!!

그래서 이번 기회에 나만의 Convention!을 정해보자! 생각했습니다!

물론, 어떤 집단에 들어간다면 팀원과 함께 정해야겠지만요~

DATABASE

1. DATABASE의 쿼리는 전부 소문자로 작성한다!

   select * from member;

2. DATABASE의 TABLE 네이밍 전략은 단수형을 사용한다!

   create table member(
   )

3. DATABASE의 컬럼 네이밍 전략은 TABLE_COLUMN을 사용한다!

   create table member(
    member_id int,
    member_name varchar
   )

Spring Layer

기본적인 Layer 규칙은 아래와 같다! Member를 예시로!

- config
- error
    + exception
- common
- util
- member
    + application
    + presentation
    + infrastructure
    + domain
        + vo
    + converter
    + dto
        + request
        + response
        + bundle

Layer간 Data 통신

1. View -> Controller (원시값을 가진 requestDTO) -> MemberSignRequestDto
2. Controller -> Service (requestDto -> dto (원시값을 VO로 바꾼 DTO, 또는 원시데이터를 valid한 데이터!) -> MemberSignServiceDto
3. Service -> Controller (dto -> responseDto) -> MemberSignResponseDto

아래의 방향대로~~

view -> controller
MemberSignRequestDto.java

MemberSignRequestDto(){
    private String name;
    private String age;
}

controller -> service
MemberSignServiceDto.java

MemberSignServiceDto(){
    private Name name;
    private Age age;
}

service -> controller
MemberSignResponseDto.java

MemberSignResponseDto(){
    private String name;
    private String age;

네이밍 전략!

1. Controller
   • sign, edit, insert, delete
2. Service
   • create, delete, update, find, findAll
3. Repository
   • JPA Naming 전략을 따른다.

허용되는 Lombok 사용

• @RequiredArgsConstructor
• @AllArgsConstructor
• @Builder (필드가 3개 이상이면!)
• @NonNull

항상 SSR로 thymeleaf를 렌더링을 통해 진행했었는데, client의 상황을 고려해야 하는 REST 방식을 사용한다는게 미숙한 점도 많았고, 모르는 점도 많았습니다!!

그래도 나는 할 수 있다! 라는 마인드로 인프런 강의를 들으며 코드를 작성했지만,,,,REST를 REST스럽게 짜지 못했다는게 결론이 되었습니다...

단순하게, json 타입으로 데이터를 전달하면 REST API인 줄 알았지만, 실상은 달랐습니다. REST를 REST답게 사용할려면 꼭 지켜야 하는 규칙이 존재함을 알게 되었습니다.

그래서 이번에는 제가 현 상황에서 최대한 REST를 어떻게 REST답게 구현할려고 했는지에 대해 작성하려고 합니다!!

서두가 길었네요!! 바로 시작하겠습니다!!!

기존 제가 짠 방식은?

프로그래머스에서 진행하는 Spring-Baord 토이 프로젝트를 예로 현재 제가 어떻게 진행했고, 어떻게 수정할지에 대해 보여드리겠습니다!

아래의 코드는 회원가입을 진행했을 때 format 형태입니다.

• url

  http://localhost:8080/api/member

• header

  Content-Type : application/json

• body

  {
  "status": 201,
  "message": "MEMBER_SIGN_SUCCESS",
  "data": null
  }

위의 코드를 살펴보면, header에는 content-type이 존재하고 body에는 상태, 메세지, 데이터가 전달됨을 확인할 수 있습니다.

혹시 해당 스펙에서 어떤 점이 REST스럽지 못하다고 생각하실까요? . . . . . . . . . . . . . . 제 코드가 RESTFUL하지 않은 이유!!는 아래와 같습니다!

1) Non Cacheable 2) Non Uniform Interface

• self-descriptive messages
• hypermedia as the engine of application state(HATEOAS)

제가 기획한 api는 Rest를 모방한, REST스럽지 못하고 REST가 아닌 코드가 되었습니다.ㅜㅜㅜ

그래서 Rest란?

Representational State Transfer의 약자로서 인터넷에서 컴퓨터 시스템 간의 상호 운용성을 제공하는 방법입니다.

로이 필딩이 HTTP 기획 작업에 참여하면서 웹 환경의 정합성과 상호 운영성 등을 개선하기 위해서 만든 모델이 HTTP Object Model이라고 합니다. 그리고 이것이 REST의 시초가 되었다고 합니다!

REST는 SOAP과 다르게 프로토콜이 아닌 아키텍쳐입니다. 하나의 구성이자, 약속이므로 필딩이 트위터와 블로그에 계속 언급하다시피, REST의 제약조건을 따르지 않으면, REST가 될 수 없습니다 ... 그저 단순한 api?

For Restful with Architectural Constraints

REST 공식 홈페이지에서 나와 있는 것 처럼, REST의 제약조건은 크게 6가지로 지정되어 있습니다.

1. Uniform interface
2. Client–server
3. Stateless
4. Cacheable
5. Layered system
6. Code on demand (optional)

Uniform interface

URL로 지정된 리소스에 대한 조작을 통일하고 한정된 인터페이스로 수행하는 아키텍쳐 스타일, 이렇게 추상적으로 정의를 내린 이유는 추가적인 확장에 있어 느슨한 결합을 유지하기 위함입니다!

Uniform interface에는 4가지의 세부사항이 존재합니다!

1. identification of resources 각각의 리소스(비디오, 문서, 이미지 등)가 하나 이상의 유일성을 가진 특정 URI를 가져야 함을 의미합니다.

Resouce가 단일한 URL에 매핑되어 리소스에 대한 관리가 진행될 때 Rest 제약조건을 갖추게 됩니다.

여기서 파생된 규칙은 URL를 명칭할때 동사가 아닌, 명사형으로 URL를 구분해야 한다고 합니다.

GET /member/delete/id/1 (X)

위의 코드처럼 동사형으로 URL를 가져가는 것이 아니라, 아래의 코드처럼 적절한 HTTP METHOD와 자원을 식별할 수 있는 명사형 명칭을 통해 URI를 구성해야 합니다!

DELETE /member/1

해당 규칙의 경우에는 일반적으로 HTTP Method를 사용할 때 지켜지는 것 같습니다. 대부분의 개발자분들이 해당 규칙은 지킨다고 생각합니다.

2. manipulation of resources through representations 리소스를 요청할 때 서버는 리소스 표현으로 응답해야 하는 것을 의미합니다.

공식문서에 따르면, 표현은 해당 바이트를 설명하는 메타데이터어떤 목적을 가지고 만들어진 데이터와 함께 바이트 시퀀스를 통해 클라이언트가 식별할 수 있는 리소스를 제공해야 함을 의미합니다.

이 메타데이터를 표현하는 미디어 유형(HTML, JSON 및 XML)이라고 합니다.

클라이언트는 서버가 보낸 리소스가 무엇인지 알 수 없습니다. 추론 또는 상황에 맞추어 판단할 뿐, 이것이 실제 무엇인지는 확신할 수 없게 됩니다.

그렇기 때문에 아래의 코드처럼 특정 리소스를 표현하는 방식을 header에 담아서 요청하고, 응답함으로서 해당 리소스가 어떠한 유형으로 제공되는지 알 수 있게 됩니다.

표현 방식의 유연성과 확실한 미디어 매체 정보를 알려줄 수 있게 됩니다.

Accept: application/json

or

Accept: text/plain

--> 해당 부분도 대다수의 사람들이 까먹지 않고, 구현하는 부분인 것 같네용

3. self-descriptive messages

   자기 설명 메시지??

말그대로 본인을 해석할 수 있는 정보를 본인이 갖고 있어야 함을 의미합니다!

아래의 코드는 앞서 보여드렸던 제 토이 프로젝트 코드입니다.

http://localhost:8080/api/member

Content-Type : application/json

{
  "status": 201,
  "message": "MEMBER_SIGN_SUCCESS",
  "data": null
}

여기서 스스로에 대한 정보를 해석할 수 없는 부분은 status, message, data가 있습니다. client는 미디어 타입에 대해 추론할 수는 있지만, 실제로 정확하게 이 데이터가 무엇인지 알 수 없습니다.

그렇기 때문에 해당 정보를 클라이언트에게 알려주기 위해 미디어 타입 문서를 작성하거나, 혹은 프로파일을 통해 미디어 타입에 대한 정보를 제공해야 합니다.

아래의 두가지 버전은 self-descriptive를 만족시키는 방법입니다.

http://localhost:8080/api/member

Content-Type : application/donggeon+json

{
  "status": 201,
  "message": "MEMBER_SIGN_SUCCESS",
  "data": null
}

http://localhost:8080/api/member

Content-Type : application/json
Link: <http//donggeon.github.io/docs/rest>; rel="profile"

{
  "status": 201,
  "message": "MEMBER_SIGN_SUCCESS",
  "data": null
}

--> 이 부분에 대해서는 많은 개발자분들이 빠트리고 개발을 진행한다고 하시네요!! 저 또한 고려해보지 못한 부분입니다!

4. hypermedia as the engine of application state

   축약하여 헤티오스 HATEOAS라고 합니다!

헤티오스는 애플리케이션의 상태를 하이퍼링크를 통해 전이되어야 함을 의미합니다.

<그런 Rest Api로 괜찮은가? 에서..>

위의 사진은 DEVIEW 2017에서 이응준님께서 강의 해주신 ppt의 일부분을 발췌한 것입니다.

헤티오스는 api를 호출하고 응답하게 되면, 응답시에 다음 로직에서 필요한 애플리케이션의 api 호출을 담아서 제공하는 규칙을 의미합니다.

짧게 다음 상태에 대한 변이 내용을 담아서 보내도록 response를 구성해야 됨을 의미합니다.

글 목록 보기를 통해 제공된 데이터에 다음 단계의 api를 담아서 보내게 됩니다. 그렇게 진행하게 된다면, 프론트에서 하드코딩으로 상태전이를 진행할 필요 없이 server에서 내려주는 응답만으로도 상태를 변경할 수 있게 됩니다.

아래의 코드는 상태 전이를 헤더에서 진행하는 방법입니다.

http://localhost:8080/api/member
Location: /api/member/login
Content-Type : application/donggeon+json

{
  "status": 201,
  "message": "MEMBER_SIGN_SUCCESS",
  "data": null
}

아래의 코드는 상태 전이를 body에서 진행하는 방법입니다.

http://localhost:8080/api/member
Content-Type : application/donggeon+json

{
  "status": 201,
  "message": "MEMBER_SIGN_SUCCESS",
  "data": null,
  "link" : {
          "login" : "/api/member/login"
  }
}

server에서 모든 정보를 제공하기 때문에 어떤 Client가 오더라도 상호 운용이 가능하게 됩니다.

더불어 Server의 기능이 변경되거나 Client의 기능이 변경되더라도 상호 독립적으로 운영할 수 있기 때문에 보다 탄력적인 확장이 가능하게 됩니다!!

--> 헤티오스를 적용하는 강의나 혹은 개발 준비생은 극히 드문것 같습니다.ㅜㅜㅜ 이번에 저도 처음 알게 되었습니다!!

Client–server

해당 제약 조건은 클라이언트와 서버가 서로에 대한 종속성 없이 별도로 발전할 수 있어야 함을 의미합니다. 클라이언트는 리소스 URI만 알아야 합니다. 그 이상의 것은 추후의 확장 혹은 이전 버전에 부정적인 영향을 미칠 수 있기 때문에 최소 수준으로 간단함을 유지해야 하는 제약조건입니다.

결론적으로 어떤 클라이언트 프로그램이든, 어떤 서버 프로그램이든 동작해야 함을 의미합니다.

Stateless

클라이언트와 서버간에 상호 작용을 진행할 때 각각의 상태를 비저장으로 유지하는 것을 의미합니다. 서버는 클라이언트가 만든 최신 HTTP 요청에 대해 아무 것도 저장하지 않고 무조건 모든 요청을 새 것으로 처리합니다.

대신에 클라이언트는 사용자를 위한 상태 저장을 진행할 수 있는 응용 프로그램이어야 하며, 클라이언트는 애플리케이션의 상태를 관리할 책임을 갖게 됩니다.

그렇기에 서버는 요청에 대한 응답만 할 뿐, 응답 중 발생하는 상태에 대한 정보를 관리하지 않고, 클라이언트만이 관리하게 됩니다.

Cacheable

캐싱은 부하가 감소했기 때문에 클라이언트 측의 성능 향상과 서버의 확장성 범위를 향상시킬 수 있습니다.

그렇기 때문에 REST에서는 캐싱이 적용 가능한 경우, 리소스에 대한 캐싱을 적용해야 하고, 리소스가 캐싱이 가능하다고 알려야 합니다.

캐싱을 통해 클라이언트와 서버간의 확장성과 성능을 증대시킬 수 있습니다.

--> 해당 부분은 아직 학습이 미흡하여 진행하지 못했습니다.ㅜㅜ 추후에 서버에 캐싱을 하여 데이터를 제공하는 예제를 올리겠습니다!

Layered system

Rest를 사용하게 되면 계층화 시스템 아키텍처를 도입할 수 있습니다!!

데이터를 어떤 서버에서 저장할지, API를 어떤 서버에서 제공할지, 인증과 인가를 어떤 서버에서 진행할지 클라이언트를 확인할 필요도, 알려고 할 필요도 없게 됩니다!

단순하게 제공된 리소스를 받기만 하면 되기 때문입니당!!

그렇기 때문에 REST를 사용하게 되면 서버를 계층화시키고 분산시킬 수 있는 장점이 있습니다!

Code on demand (optional)

클라이언트가 리소스에 대한 표현을 응답으로 받고 처리하는데, 어떻게 처리해야 하는지에 대해 서버가 코드를 제공하는 것을 의미합니다.

예를 들어 클라이언트가 특정 기능을 요청하면, 그 기능을 제공하는 자바스크립트를 클라이언트에게 응답할 수 있습니다.!!

글을 마치며

REST를 만드신 분의 말씀은 아래와 같습니다..

한,두개의 제약조건을 어겨도 좋다.. 하지만, 그것은 진정한 RESTFUL이 아니다..라고 말씀하셨습니다.

REST를 REST답게 사용하기 위해서는 만드신 분이 설정하는 제약조건을 무조건적으로 따라야함을 알 수 있었습니다...

동건동건동건 REST 회고...

이번에 REST를 학습하면서, 제가 얼마나 무지했는지 알게 되었습니다. 포스팅을 하면서 제가 짠 코드를 수정한다고 했지만, 결국에는 REST의 제약조건을 다 맞추지 못해 REST가 아닌 REST API를 짜게 되었습니다ㅜㅜ

위에서 설명한 REST 제약 조건말고도 다양한 REST 제약조건이 존재합니다! 아래의 블로그를 통해 확인하시면 될 것 같습니다!!

그 외에도 RESTFUL하게 짜기 위한 다양한 규칙들이 존재합니다!

• 설계 가이드

변명 시작

이번 달은 쉬는 날이 많았어요.. 그러다 보니,,, 공부를 많이 못했던 것 같아요.. 연휴가 끝나고 나서 일상이 불바다?가 된 것을 느끼게 된 것 같네요

역시 일은 그날그날 마무리해야 합니다..ㅜㅜㅜ

1일 1커밋에 대해

동료분들이 1일 1커밋을 하는 저를 보고 많이 놀라셨어요! 그렇게 열심히 깃허브를 관리한다고 생각하지 못했는데, 우연히 1일 1커밋을 하게 된 것 같네요!

저는 하루에 2시간은 무조건 프로그래밍을 하자! 라는 생각을 갖고 있어요. 그러다 보니 자동적으로 잔디밭을 채울 수 있게 된 것 같네요!!

프로그래머스 교육과정을 진행하며

프로그래머스 백엔드 데브코스를 진행하며 많은 것을 배우게 된 것 같아요. 기존에 알고 있던 내용이라도, 다시 한번 생각해 볼 수 있는 기회를 갖게 된 것 같습니다!

프로그래머스 감사해요!!!

최근 근황?

요즘은 알고리즘 문제를 최대한 자주 풀려고 노력해요. 꾸준히 준비하면 언제가는 어떤 문제도 풀 수 있지 않을까? 생각합니다.

그리고 인프런 강의와 개인적인 프로젝트를 꾸준하게 하고 있어요!! 2021년도에는 힘든 일도 많았고, 사람에 치이기도 했는데, 하반기가 되면 좋은 사람들을 많이 만나게 되어 정신적 회복을 진행하고 있습니다!

앞으로

앞으로는 노는 시간을 더 줄이려고 해요!! 중간 중간 쉬는 시간을 두었다면, 이제는 조금 더 공부에 몰두할려고 해요!!

미래는 스스로 만들어야 하니까요!

처음 회고를 작성하고 거의 한달이 넘는 시간이 흐른 것 같습니다. 열심히 해야지! 나는 글도 잘 작성하는 개발자가 될거야!라는 마음가짐은 어디로 갔는지 참.... 우주 저 멀리 떠나 버린 것 같아 오늘도 반성하게 되네요

아마 저 별 어딘가에 제 멘탈도 같이 있는 것 같네요

번 아웃

열심히 공부한다고 생각했는데... 생각보다 실력이 엄청나게? 늘리지는 않고... 계속 같은 자리에 머무는 것 같다고 생각들었어요

아마도 이건, 제가 기본에 충실히 하지 않았기 때문에 발생한 문제라고 생각들어요

그래서 최근 한달?간 조금 쉬면서 공부했던 것 같습니다

하지만, 쉬면서도 쉬는게 아닌 일상이었어요 취업,,, 취업....취업.... 나도 개발자가 될 수 있을까? 라는 고민을 계속 했던 것 같습니다.ㅜㅜ

앞으로의 도전!

코딩이 취업의 전부가 아니라고 어떤 분이 말씀 해주신게 생각났습니다. 저는 이제 개발자가 되기 위해 준비해야 될게 많은데 그것을 준비하지 못했던 것 같네요!

앞으로는 CS와 알고리즘도 꾸준히 공부할 예정입니다!ㅜㅜㅜ

마치며

기본기와 꾸준함이 중요하다고 다들 말하지만, 전 어느하나 제대로 한게 없네요

이번 기회에 다시 저를 재조립해야 함을 느끼게 된 것 같습니다!

모두 취업하는 그날까지 파이팅!

그래서 이번에는, AOP를 왜 쓰고, 어떻게 쓰는지에 대해 중점을 가지며 학습했습니다.

AOP란?

AOP는 Asepct Oriented Programming의 약자로서 관점 지향 프로그래밍을 의미합니다. 관심사의 분리를 통해 모듈성을 높이는 것을 목표로 하는 프로그래밍 패러다임입니다.

위의 사진을 보면, 치킨집과 쿠팡은 각기 다른 서비스를 제공하는 것을 알 수 있습니다.

치킨집은 주문을 받은 뒤, 치킨을 만들기 위한 재료를 통해 조리를 하고, 조리된 음식을 포장한 이후에 배달을 진행합니다.

쿠팡의 경우에는 주문을 받고, 요청된 물건을 정리한 뒤, 정리된 물건을 포장하고 배달을 진행합니다.

핵심기능 관점에서 치킨집과 쿠팡이 하는 업무는 다릅니다. 치킨집은 요식업과 관련된 기능을 제공하고, 쿠팡은 물류배송 서비스를 제공합니다.

하지만 부가기능 관점으로 바라본다면, 주문받기와 배달하기는 핵심적인 비즈니스로직이라기 보다는 부가적인 기능으로 생각할 수 있다. 정말 핵심적인 기능은 요청된 주문을 어떻게 처리할지에 대한 내용을 담은 2번과 3번이라고 할 수 있습니다.

이렇게 핵심적인 비즈니스 로직은 아니지만, 반드시 진행해야 되는 반복적인 작업을 정리하는데 사용하는 기술이 AOP입니다.

AOP는 관점 지향 프로그래밍이라는 명칭을 갖고 있지만, 객체지향 프로그래밍을 대체하는 기술은 아닙니다. 개발자가 실제 비즈니스 로직에 더 집중할 수 있도록 부가적인 로직을 분리시켜 한층 더 추상화를 진행할 수 있게 됨으로서 OOP를 더 OOP스럽게 만들 수 있는 보조자 역할을 맡습니다.

OOP는 중복된 다수의 기능이 존재하더라도 객체가 책임을 같고 로직을 수행하도록 구성되게 됩니다. 이렇게 진행될 경우, 불가피하게 중복된 다양한 코드가 발생하게 되고 수정과 확장시 복잡한 구조와 중복된 코드로 어려움을 겪을 수 있습니다.

하지만 AOP를 같이 적용하게 되면서 실제 중요하게 사용되는 비즈니스 도메인을 OOP를 통해 구체화시키고, AOP를 통해 부가적인 기능인 트랜잭션, 로깅, 모니터링과 같은 기능을 수행할 수 있게 됩니다.

AOP에서 쓰이는 용어

• Target

Target은 부가기능을 제공할 대상을 의미합니다. 주문받기, 배달하기 등의 부가기능을 제공받을 대상인 치킨집이 Target이 됩니다.

• Advice

Advice는 부가기능 자체를 의미합니다. 주문받기와 같이 부가기능을 담은 구현체 자체이며, 어떠한 기능이 언제 사용될지 정의합니다. 주문받기가 언제 사용될지 정의된 구현체를 의미합니다.

• JoinPoint

JoinPoint는 Advice가 적용될 위치를 의미합니다. 해당 Advice가 어느 메서드에 실행되는지를 의미합니다.

• PointCut

PointCut은 Advice를 적용할 JoinPoint를 선별하는 기능을 제공합니다. 결국 포인트컷은 부가기능이 적용될 대상을 선정하는 방법이라고 할 수 있습니다. 주문받기라는 기능이 치킨집 또는 쿠팡의 어떠한 특정 메서드에서 실행될지 설정할 수 있습니다.

• Aspect

Aspect는 핵심기능에 부가되어 의미를 갖도록하는 부가기능이 모여진 모듈을 의미합니다. Advice와 PointCut 등 부가기능을 다루기 위한 모듈이 모인 집합입니다.

• Proxy

Proxy는 타겟을 랩핑한 오브젝트입니다. 어플리케이션에서 타켓을 호출하게 되면 Proxy가 호출되어 실행전, 후에 필요한 기능을 실핼시킬 수 있습니다.

코드를 통해 이해하자!

실제 코드로 AOP를 적용하면서 AOP에 대해 간략하게 학습을 진행했습니다.

@Component
public class ChickenHouse {

    public void open(){
        System.out.println("환영합니다! 치킨집입니당!");
    }

    public void makeChicken() {
        System.out.println("재료를 가공하고 튀김기를 통해 조리하기");
    }

    public void packChicken() {
        System.out.println("조리된 음식을 박스에 포장하기");
    }

    public void nonException() {
        System.out.println("제대로 실행되었습니다!");
    }

    public void exception() {
        throw new RuntimeException("예외 발생!");
    }
}

ChickenHouse의 경우에는 간단한 메서드를 담고 있는 클래스입니다. 해당 클래스를 통해 Aop를 Test해봤습니다.

package com.example.springaop;

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.*;
import org.springframework.stereotype.Component;

@Aspect 
@Component 
public class ChickenHouseAspect {
    ...
}

ChickenHouseAspect 클래스를 구성하였고 해당 클래스에 부가기능을 담았습니다. Aspect 어노테이션을 통해 해당 클래스가 Aspect로서 기능한다는 것을 명시할 수 있습니다.

@Pointcut("execution(* com.example.springaop.ChickenHouse.*(..))")    
public void commonPointcut() {
}

Pointcut 어노테이션을 통해 해당 Adivce가 어떤 로직이 수반된 이후에 동작할 것인지 명시할 수 있습니다.

@Before("execution(* com.example.springaop.ChickenHouse.makeChicken(..))")
public void before(JoinPoint joinPoint) {
     System.out.println(joinPoint.getSignature().getName() +
                " : 실행전 먼저, 주문을 요청 받습니다!");
}

Before 어노테이션의 경우에는 pointcut으로 지정한 로직이 수행되기 이전에 부가기능이 실행되도록 하는 기능을 제공합니다.

@After("execution(* com.example.springaop.ChickenHouse.packChicken(..))")
public void after(JoinPoint joinPoint) {
     System.out.println(joinPoint.getSignature().getName() + " : 실행후, 배달을 시작합니다.");
}

After 어노테이션은 pointcut으로 지정된 로직이 수행된 이후에 부가기능이 실행되도록 지원합니다.

@Pointcut("execution(* com.example.springaop.ChickenHouse.returnNumber())")
public void returnNumber() {
}

@AfterReturning(pointcut = "returnNumber()", returning = "value")
public void afterReturning(JoinPoint joinPoint, int value) {
      System.out.println(joinPoint.getSignature().getName() + " : 반환된 값은 : " + value);
}

AfterReturning 어노테이션은 지정된 로직이 정상적으로 실행된 이후에 반환된 값을 받아서 추후 처리를 진행할 수 있는 기능을 제공합니다.

@AfterThrowing(value = "execution(* com.example.springaop.ChickenHouse.exception(..))", throwing = "e")
public void afterThrowing(JoinPoint joinPoint, Exception e) throws RuntimeException {
     System.out.println(joinPoint.getSignature().getName() + " : exception이 터졌습니다!!");
    System.out.println("exception : " + e.toString());
}

AfterThrowing 어노테이션은 지정된 로직에서 Exception이 발생했을 경우 해당 Exception을 받아서 추후 로직을 처리할 수 있는 기능을 제공합니다.

@Around("execution(* com.example.springaop.ChickenHouse.open())")
public void around(ProceedingJoinPoint joinPoint) throws Throwable {
     System.out.println("-----------------실행전---------------");
     joinPoint.proceed();
     System.out.println("-----------------실행후---------------");
}

Around 어노테이션은 지정된 로직이 실행되기 전, 그리고 실행된 이후에 수행될 부가기능을 설정할 수 있습니다.

이번 스터디에서는 간단하게 AOP를 왜 사용하는지, 그리고 어떻게 사용해야 하는지에 대해 학습했습니다.

이번에는 제가 스터디에서 배웠던 SSR과 CSR에 대해 정리해보는 시간을 가지려고 합니다!

SSR이란?

서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식을 의미합니다!

Spring MVC에서 JSP 또는 Thymeleaf를 통해 서버렌더링으로 사용자에게 화면을 보여주게 합니다! 이러한 방식을 SSR이라고 합니다

SSR을 사용하게 되면, 서버에서 사용자에게 보여줄 화면을 미리 다 랜더링하여 제공하게 됩니다!

그렇기 때문에, client가 특정 UI에 대한 화면을 요청했을 경우 CSR보다 상대적으로 속도가 느리다는 단점이 존재합니다. 더불어 모든 요청과 랜더링을 서버에서 진행하다보니 서버가 가지는 역할과 책임이 너무 방대해질 수 있습니다

저희 학교 메인 홈페이지의 경우 SSR로 시스템이 운영되고 있습니다. 사용자의 요청이 들어왔을 경우, 전체 소스파일과 페이지를 랜더링하여 사용자에게 제공하게 되어있습니다. 그렇기 때문에 상대적으로 요청시 응답이 늦어지는 문제가 있습니다.

처음 이벤트가 발생한 이후에 추가적인 이벤트가 발생하지 않고 있습니다. 모든 데이터가 일시에 파싱되어 사용자에게 제공됨을 확인할 수 있습니다.

CSR이란?

브라우저에서 페이지를 직접 렌더링하는 것을 의미합니다. 모든 로직, 데이터, 템플릿 및 라우팅을 서버가 아닌 Client에서 처리합니다.

Client가 특정 페이지를 요청했을 경우, 각각의 이벤트가 순서대로 동작하면서, 서버로부터 데이터를 할당하여 클라이언트 자체에서 html을 파싱합니다.

그렇기 때문에, 첫 로딩 이후 전체 페이지가 구성되기 까지 SSR보다 더 많은 시간이 들게 됩니다.

하지만 CSR의 경우에는 첫 로딩이 된 이후 부터, 요청된 부분만을 다시 읽어 랜더링하기 때문에 이후 웹 환경은 SSR보다 빠르게 이용할 수 있습니다.

SSR을 대신하여 CSR을 쓰는 이유

SSR은 CSR보다 초기 구동 속도가 빠릅니다. 이미 만들어진 view를 랜더링하기 때문에, 서버로부터 자원을 할당받고 랜더링하는 CSR보다는 화면이 빠르게 떠질 수 있습니다!

하지만, 동적인 웹, REACT를 활용한 DOM 관리등 CSR을 위한 프레임워크가 다수 등장하면서 SSR대신 CSR에 대한 인기가 커지고 있습니다

많은 요청이 발생했을 경우, 서버에 부담을 줄 수 있는 SSR 대신, CSR 방식을 통해 서버의 부담을 줄이고, 각각의 기능을 분리함으로서 조금 더 명확하게 아키텍쳐를 구분할 수 있는 장점도 존재합니다.

IOC란?

IOC Inversion Of Control의 약자로서 번역어로 제어의 역전이라고 합니다.

웹 어플리케이션 또는 기타 어플리케이션에서 개발자가 아닌, 프레임워크가 적절한 시점에 클래스의 오브젝트를 생성하고, 전달해주는 역할을 진행하는 것을 의미합니다.

• 일반적인 프로그램

  public class Application {
    public static void main(String[] args){
        new Game(new Coin());
    }
  }

일반적인 프로그램에서는 개발자가 원하는 시점에 객체를 전달하여 프로그램의 흐름을 변경하거나, 수정하고 관리할 수 있습니다. 그렇기 때문에 개발자는 객체에 대한 생성, 초기화, 실행, 소멸 등에 대한 모든 관리와 책임을 가지게 됩니다.

• 스프링 프레임워크

  @SpringBootApplication
  public class GameApplcation(){
    public static void main(String[] args){
        SpringApplication.run(GameApplication.class, args);
    }
  }

반대로 프레임워크에서는 개발자가 원하는 객체에 대한 생성, 초기화, 실행, 소멸 등의 기능을 프레임워크의 컨테이너가 자동으로 처리해 줍니다. 이렇게 개발자가 아니라 프레임워크가 객체에 대한 관리를 대신해주는 것을 IOC라고 하며, 스프링에서는 이런 기능을 Bean Factory와 ApplicationContext를 통해 제공합니다.

Bean 등록하기

Bean Factory 또는 ApplicationContext를 통해 등록된 Bean을 가져오기 전, 먼저 Bean을 등록하는 작업이 필요합니다

1. xml 기반 Bean 등록

   <?xml version="1.0" encoding="UTF-8"?>
   <beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
   
    <bean id="game"
          class="spring.ex.model.Game" />
   </beans>

xml 설정 파일을 통해 Game이라는 클래스를 Bean으로 등록할 수 있습니다. Bean의 id값과 해당 class의 위치 정보를 표기함으로써 Bean을 등록할 수 있습니다.

2. component-scan 기반 Bean 등록

   <?xml version="1.0" encoding="UTF-8"?>
   <beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:context="http://www.springframework.org/schema/context"
      xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">
   
   <context:component-scan base-package="spring.ex.model" />
   

Bean으로 등록할 객체에 @Component 어노테이션을 주기하면, 스프링은 해당 어노테이션을 확인하고, component-scan을 통해 해당 객체를 Bean으로 등록합니다!

@Service 또는 @Respository와 같은 어노테이션을 들어가면, 최종적으로 @Component가 들어있음을 확인할 수 있습니다.

여기서 @Component는 @Bean과 유사하다고 느껴지지만, 조금의 차이점이 존재합니다.

@Bean의 경우에는 개발자가 컨트롤이 불가능한 외부 라이브러리를 Bean으로 등록하고 싶은 경우에 사용됩니다. 컬렉션과 같이 제공되는 라이브러리를 Bean으로 등록할 때 사용됩니다. 메서드 기반으로 Bean을 등록하게 되어 있습니다.

@Bean
public ObjectMapper objectMapper(){
    return new ObjectMapper();
}

반대로, @Component의 경우에는 개발자가 직접 컨트롤 가능한 클래스에 사용됩니다. 여기서 직접 컨트롤 가능하다는 것은, 개발자 직접 구현한 클래스를 의미합니다. 해당 방식의 경우에는 class 기반으로 Bean을 등록하게 됩니다.

@Component
public class Game {

}

개발자가 임의로 @Bean 또는 @Component를 설정하는게 아니라, 각각의 type에 맞추어 어노테이션을 설정해야 합니다. 만약 type에 맞추어 설정하지 않는 경우에는 컴파일 에러가 발생할 수 있습니다.

@Target({ElementType.METHOD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Bean {
}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed
public @interface Component {
}

@Bean과 @Component를 들어가보면, 해당 어노테이션이 어떤 Type을 가져야 되는지 확인할 수 있습니다!

public class GameApplication {

    public static void main(String[] args) {

        ApplicationContext context = new ClassPathXmlApplicationContext("application.xml");
    }
}

application.xml에 등록한 Component들을 ClassPathXmlApplicationContext을 통해 읽어들여서 해당 Component 정보를 ApplicationContext로 가지고 있게 됩니다.

3. Config

   import org.springframework.context.annotation.Bean;
   import org.springframework.context.annotation.Configuration;
   

@Configuration public class ApplicationConfig {

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

}

config 파일을 통해 PasswordEncoder를 Bean으로 등록할 수 있습니다.

등록하고 싶은 객체를 메서드를 통해 Bean으로 등록하겠다고 표기를 진행합니다.
이후에 해당 ApplicationConfig.class에 @Configuration 어노테이션을 명시하여 해당 클래스에서 1개 이상의 Bean을 생성하고 있음을 명시해야 합니다!

`@Configuration` 어노테이션을 통해 해당 클래스가 스프링에서 Bean 등록을 위해 사용된 Config라는 것을 명시할 수 있게 됩니다! 더불어 해당 클래스의 싱글톤을 유지시킬 수 있습니다



<br>

4. component-scan 과 Config
```java
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan(basePackageClasses = GameApplication.class) 
public class ApplicationConfig {

}

@ComponentScan(basePackageClasses = GameApplication.class) 특정 위치의( 특정 패키지)에 대한 Component를 스캔하여 Bean으로 등록할 수 있는 기능을 제공합니다.

하나의 class가 될 수 있고, 또는 패키지 위치를 지정하여 패키지 안에 있는 모든 컴포넌트들을 Bean으로 등록할 수 있습니다.

5. SpringBootApplication

   @SpringBootApplication
   public class GameApplication {
    public static void main(String[] args) {
        SpringApplication.run(GameApplication.class, args);
    }
   }

이전까지 개발자가 직접 Config 파일을 통해서 등록하거나, 혹은 Component-scan을 돌려서 해당 패키지 또는 id값을 통해 읽어들이는 과정을 SpringBoot에서는 @SpringBootApplication이라는 어노테이션을 통해 제공하게 됩니다.

결론적으로, 별다른 Config 파일 없이 @Component가 등록된 파일을 모두 스캔할 수 있는 기능을 제공합니다.

Spring Container

Bean에 대한 관리를 수행하는 곳을 Spring Container라고 합니다. Bean의 생성, 연결, 설정 그리고 생명주기를 관리하는 역할을 맡습니다.

자세하게는 애플리케이션에 대해 정의한 메타데이터를 읽어 인스턴스화, 구성 및 관리할 개체에 대한 정보를 얻을 수 있습니다! 여기서 메타데이터는 스프링 컨테이너가 애플리케이션의 객체를 어떻게 인스턴스화하고, 설정하고, 조합해야 하는지 지시하기 위한 정보를 의미합니다. 위에서 자가성한 xml, annotation 그리고 java 파일 등이 메타데이터의 일환입니다!

스프링 컨테이너의 기능을 제공하는 인터페이스는 BeanFactory와 ApplicationContext가 존재합니다.

Bean Factory

인스턴스를 생성하면서 설정하고 많은 수의 Bean을 관리하는 실질적인 컨테이너를 의미합니다. Bean들은 일반적으로 서로 의존성을 가진 협력관계이며, BeanFactory에 의해 사용된 설정 데이터가 반영되게 됩니다.

여기서 컨테이너는 특정 클래스를 상속하거나 인터페이스를 구현하지 않는 POJO를 이용해 EJB의 기능을 유지하면서 복잡성을 제거하고, 라이프 사이클을 관리해주면서 개발자가 작성한 코드 또는 외부 라이브러리 등에 대한 처리과정을 위임받아 Bean을 관리합니다

주요 메서드는 아래와 같습니다!

// 애플리케이션 전체에서 공유되거나 독립적일 수 있는 지정된 bean의 인스턴스를 리턴
getBean() 

// 빈 팩토리에 주어진 이름의 빈이 포함되어 있는지 확인
containsBean()

// 해당 빈이 동일한 인스턴스를 반환하는지 확인
isSingleton()

// 해당 빈이 항상 독립된 인스턴스를 반환하는지 확인
isPrototype()

// 지정된 이름의 빈이 지정된 유형과 일치하는지 확인
isTypeMatch()

// 주어진 이름이 어떤 빈의 유형을 가졌는지 확인
getType()

// 주어진 이름이 어떤 별칭을 가졌는지 확인
getAliases()

ApplicationContext

EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver 을 implement하여 Bean Factory 보다 더 많은 기능을 제공합니다.

ApplicationContext를 통해 Bean에 대한 관리를 더욱 용이하게 진행할 수 있습니다.

공통적으로 BeanFactory와 ApplicationContext가 비슷한 기능을 제공하게 됩니다.

Bean Factory와 ApplicationContext 차이점

1. BeanFactory는 요청 시 빈을 로드하는 반면 ApplicationContext 는 시작 시 모든 빈을 로드

Game이라는 class를 생성하고 Bean 로드를 확인하기 위한 표기를 위해 isBeanInstantiated 필드를 선언합니다.

public class GameBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
    private static boolean isBeanFactoryPostProcessorRegistered = false;

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory){
        setBeanFactoryPostProcessorRegistered(true);
    }

    public static boolean isBeanFactoryPostProcessorRegistered() {
        return isBeanFactoryPostProcessorRegistered;
    }

    public static void setBeanFactoryPostProcessorRegistered(boolean isBeanFactoryPostProcessorRegistered) {
        GameBeanFactoryPostProcessor.isBeanFactoryPostProcessorRegistered = isBeanFactoryPostProcessorRegistered;
    }
}

Bean에 대한 등록을 위해 id와 class위치 그리고 init-method 방법을 기입합니다.

<bean id="game" class="spring.ex.model.Game" init-method="postConstruct"/>

Game의 필드값이 true로 변경되었는지 test를 통해 확인을 진행합니다!

@Test
@Display("BeanFactory를 통한 초기화 확인 실패")
public void whenBFInitialized_thenGametNotInitialized_FAIL() {
    BeanFactory factory = new XmlBeanFactory(new ClassPathResource("bean-factory.xml"));

    assertThat(Game.isBeanInstantiated(), is(false));
}

실제로 Test를 돌린 결과, Game에 대한 초기화는 진행되지 않았습니다. 그 이유는 BeanFactory에 대한 초기화만 진행되었고, xml에 정의된 Game에 대해서는 진행되지 않았기 때문입니다. BeanFactory는 getBean()통해서 Bean에 대한 초기화가 가능하기 때문입니다.

@Test
@Display("BeanFactory를 통한 초기화 확인 성공")
public void whenBFInitialized_thenGameNotInitialized_SUCCESS() {
    BeanFactory factory = new XmlBeanFactory(new ClassPathResource("bean-factory.xml"));

    Game game = (Game) factory.getBean("game");

    assertThat(Game.isBeanInstantiated(), is(true));
}

BeanFactory에 경우에는 진짜 해당 Bean이 필요한 경우에 요청에 의해서 초기화가 진행됩니다. 이러한 초기화를 지연 로딩 Lazy Loading이라고 합니다.

반대로, ApplicationContext의 경우에는 즉시 로딩 Eager Loading을 통해 Bean을 관리합니다.

@Test
public void whenAppContInitialized_thenGameInitialized() {
    ApplicationContext context = new ClassPathXmlApplicationContext("bean-factory.xml");

    assertThat(Game.isBeanInstantiated(), is(true));
}

ApplicationContext는 즉시로딩을 통해 runtime시 모든 bean을 확인합니다.

그렇기 때문에, ApplicationContext는 BeanFactory에 비해 개발자가 직접 관리해야 되는 부담은 적지만 한번에 전체 Bean을 로드하기 때문에 메모리를 많이 잡아 먹는 문제가 존재합니다.

반대로 BeanFactory의 경우에는 개발자가 원하는 타임에 Bean을 로드할 수 있는 장점이 존재하고 메모리에 대한 관리를 진행할 수 있게 됩니다. 하지만 getBean()을 통해서 로드를 해야 한다는 문제가 존재합니다.

하지만, Spring에서는 ApplicationContext를 사용하는 것을 지향합니다. 그 이유는 BeanFactory의 경우에는 Singleton과 Prototype에 해당하는 두 가지 Type만을 지원하지만, ApplicationContext는 웹 어플리케이션에서 사용되는 대다수의 type을 지원하기 때문입니다.

2. ApplicationContext는 시작시 BeanFactoryPostProcessor와BeanPostProcessor를 로드, Beanfactory는 요청시 로드

postProcessBeanFactory와 BeanPostProcessor가 즉시 로딩이 되는지 확인하기 위해 해당 클래스를 정의합니다.

public class Game {
    private static boolean isBeanFactoryPostProcessorRegistered  = false;

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory){
        setBeanFactoryPostProcessorRegistered(true);
    }

    public static boolean isBeanFactoryPostProcessorRegistered() {
        return isBeanInstantiated;
    }

    public static void setBeanFactoryPostProcessorRegistered(boolean isBeanInstantiated) {
        Game.isBeanInstantiated = isBeanInstantiated;
    }
}

public class GameBeanPostProcessor implements BeanPostProcessor {
    private static boolean isBeanPostProcessorRegistered = false;

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName){
        setBeanPostProcessorRegistered(true);
        return bean;
    }

    public static boolean isBeanPostProcessorRegistered() {
        return isBeanPostProcessorRegistered;
    }

    public static void setBeanPostProcessorRegistered(boolean isBeanPostProcessorRegistered) {
        GameBeanPostProcessor.isBeanPostProcessorRegistered = isBeanPostProcessorRegistered;
    }
}

<bean id="gameBeanPostProcessor" 
  class="spring.ex.model.GameBeanPostProcessor" />
<bean id="gameBeanFactoryPostProcessor" 
  class="spring.ex.model.GameBeanFactoryPostProcessor" />

xml에 해당 bean에 대한 정보를 기입합니다.

@Test
public void whenBFInitialized_thenBFPProcessorAndBPProcessorNotRegAutomatically() {
    Resource res = new ClassPathResource("bean-factory.xml");
    ConfigurableListableBeanFactory factory = new XmlBeanFactory(res);

    assertThat(GameBeanFactoryPostProcessor.isBeanFactoryPostProcessorRegistered(), is(false));
    assertThat(GameBeanPostProcessor.isBeanPostProcessorRegistered(), is(false));
}

test를 통해 bean을 xml에 정의했다고 하더라도, 즉시로딩이 되지 않음을 확인할 수 있었습니다. BeanFactory의 경우에는 BeanFactoryPostProcessor와 BeanPostProcessor를 요청시에 로드하기 때문에 test가 실패함을 알 수 있습니다.

반면에, ApplicationContex의 경우에는 run시 바로 즉시로딩이 되어 BeanFactoryPostProcessor와 BeanPostProcessor가 동작함을 확인할 수 있었습니다.

@Test
public void whenAppContInitialized_thenBFPostProcessorAndBPostProcessorRegisteredAutomatically() {
    ApplicationContext context 
      = new ClassPathXmlApplicationContext("bean-factory.xml");

    assertThat(GameBeanFactoryPostProcessor.isBeanFactoryPostProcessorRegistered(), is(true));
    assertThat(GameBeanPostProcessor.isBeanPostProcessorRegistered(), is(true));
}

결과적으로 Spring IOC 컨테이너 기능을 제공하는 ApplicationContext와 BeanFactory에 대한 차이점은 Lazy와 Eager로 나눌 수 있다고 생각합니다. 해당 방식의 차이로 인해 메모리에 대한 영향도가 달라짐을 부수적으로 확인할 수 있었습니다.

궁금한 점

• @Bean이 Type에 따라서 진행된다고 나와 있지만, 아래의 코드 처럼 사용자가 직접 구현한 코드를 등록할 때 @Bean을 붙여 등록할 수 있습니다... 그렇다면, Type에 따라 진행되는게 아니라, 형태에 따라 진행되는게 아닌지 궁금합니다!

  @Configuration
  public class ApplicationConfig {
  
    @Bean
    public Game game() {
        return new Game();
    }
  

}

계속 Velog에 글을 작성하지 못한 것 같아 아쉬움이 남습니다..ㅜㅜㅜ

최근 프로그래머스 백엔드 교육과정을 수강 중이라,, 수업 듣고 과제하기가 힘들었습니다.. 엄청 어렵거나, 힘들지는 않았지만 거북목과 일자목이라는 콜라보네이션이 저를 힘들게 하는 것 같습니다..ㅜㅜㅜ 공부하다가 어지러워 병원가서 주사 맞고,,, 계속 무한 반복,,,

그러다! 결국 헬스를 다시 시작하기로 했습니다!! 두둥!!! 운동을 하면 조금 좋아지지 않을까? 하는 생각에 2시간만 나를 위해? 써보자! 라는 결심이 들었습니다!!

너무 TMI가 많은 것 같아 저번주와 이번주에 어떤 것을 학습했는지 조금 정리해보려고 합니다.

저는 Spring 그리고 Java를 어떻게 사용해야 하고, 어떻게 써야하는지만 집중했던 것 같습니다.. 결국 저에게는 근본이 없었습니다.ㅜㅜㅜㅜ 그러다 보니 새로운 개념이 저에게 오면,, 계속 어려움을 느꼈던 것 같습니다!!

최근에는 지금까지 제가 공부했던 내용들을 다시 주서담는? 과정을 진행하고 있습니다!!

가장 첫번째로 DI와 DIP에 대해 학습했습니다!

이전까지 단순하게 DI는 스프링이 만들어서 보관하는 Bean을 자동으로 주입받는다! 까지만 알고 있었습니다. 그 원리는 무엇이고, DI를 통해 우리가 얻을 수 있는 이점이 무엇인지 몰랐던 것 같습니다.

DI는 의존성 주입으로서, 객체를 외부로 부터 주입받아 사용하는 것을 의미합니다.

DI를 할 수 있는 방법은 다양한데, 그 중에서 Setter, Constructor, Field가 대표적으로 사용되는 방법입니다

Setter의 경우에는 SetMethod를 통해 bean을 주입 받을 수 있고, Constructor는 생성자를 통해 주입받을 수 있습니다. 마지막으로 Field의 경우에는 @Autowired를 통해 주입받을 수 있습니다.

다양한 DI 방식이 존재하지만, 그중에서도 현재 권고되는 DI 방식은 생성자 주입입니다. 생성자 호출 시점에 한번만 호출되는 것을 보장합니다! 더불어 final로 선언이 가능하여 불변객체로서 오류를 방지할 수 있는 역할을 수행할 수 있습니다!!

DIP는 의존 역전 원칙을 의미하며, 구상체에 의존하는 것이 아닌, 추상체에 의존하는 것을 의미합니다! 만약 어떠한 객체가 구상체에 의존하게 된다면, 불가피한 수정이 발생했을 때 추상체도 변경해야 하는 리스크가 존재합니다.!!!

하지만, 추상체에 의존하게 되면, 이런 불가피한 수정에도 확장성을 가지며 기능을 추가할 수 있다는 장점이 존재합니다!

객체지향 공부하기!

졸업생들과 함께 하는 스터디 모임이 존재합니다! 저번주 과제는 주차장 관리 시스템을 개발하는 것이었습니다!!

해당 과제를 진행하면서, 객체가 메세지를 전달하고, 스스로에 대한 유효성을 검사할 수 있도록 로직을 구현하는 연습을 진행했습니다!!!

주차 관리 시스템

요구사항을 어떻게 작성하느냐에 따라서 객체의 설계가 달라진다는 것을 알게 되었습니다!!

한가지 아쉬운 점은 너무 Enum을 남용하여 설계하다보니, 확장성이 줄어들고 하드코딩된 부분이 많았다는 점입니다.,,,,,ㅜㅜㅜㅜ

이번 리뷰를 통해 클래스를 설계할 때 조금 더 생각?하는 습관을 들여야 함을 알게 되었습니다...

마치며

현재 너무나 많은 일들이 저에게 다가온 것 같습니다.. 하나씩 해결하면서, 스스로 성장하고 있다고 생각하지만 건강을 챙기지 못한 지나난 날의 동건에게 실망감을 갖기도 합니다.ㅜㅜㅜㅜㅜ

이제는 조금 더 건강을 지키며, 평생 가는 프로그래머가 되기 위해 노력해야 될 시기라고 생각합니다!

오늘도 동건동건동건

해당 주제는 제가 넥슨 웹개발자 면접때 받았던 질문입니다! 그럼 시작하겠습니다~

DI와 DIP에 대해 설명하시오.

• DI는 의존성 주입을 의미합니다. 객체가 다른 객체를 사용하기 위해서 본인의 내부 로직에서 외부 객체에 대한 인스턴스를 생성하는 것이 아닌, 외부로부터 인스턴스를 주입받아 사용하는 것을 의미합니다.
• DI는 생성자 주입과 필드주입이 존재하며, 대체로 외부에서 변경이 가능한 생성자 주입을 사용하는 것을 권고합니다.
• DIP는 의존성 역전 원칙을 의미합니다. 객체가 구현체에 의존하지 않고, 인터페이스를 통해 인스턴스를 할당받게 함으로서, 다형성을 증가시킬 수 있는 원칙을 의미합니다.
• DIP를 다형성을 만족할 수 있고, 이를 통해 확장에 열려있을 수 있으며, 인터페이스를 통해 변경과 변화 그리고 코드의 일관성을 지킬 수 있습니다.

DI와 DIP가 뭐지?

우리가 Spring Project를 구현하다보면, 필드 주입 또는 생성자 주입을 통해 객체를 받아서 사용할 것입니다.

보통은 아래의 코드처럼 생성자 주입을 통해 필요한 객체를 주입받아서 사용합니다

private final Book book;

public Study(Book book){
    this.book = book;
}

or

@Autowired
private Book book;

여기 매개변수로 받는 Book이 IOC 컨테이너를 통해 생성되고 주입되는 객체를 의미합니다! IOC 컨테이너에서 객체는 생성되고 사망하고...

이 부분은 너무나 방대하여 다음에 다시 정리하도록 하겠습니다!

위의 코드에서 외부에서 객체의 주입이 발생하는데.,..이런 주입을 DI Dependency Injection이라고 합니다

위의 코드처럼 외부의 주입을 통해 Study라는 Class에서 Book을 사용할 수 있습니다. 물론, Study에서 Book에 대한 인스턴스를 생성해서 사용할 수도 있습니다.

class Study {
    Book book = new Book();
}

or

class Study {
    private Book book;

    public Study(){
        book = new Book();
  }
}

위의 코드처럼 Study가 Book을 생성해서 사용할 경우 Study와 Book의 의존관계에서 결합도는 매우매우 커지게 됩니다!

의존관계에서 결합도가 높아지게 될 경우, Book이 변경되었을 때 Study는 Book과 연관된 코드를 전부 변경해야 하는 수고스러움이 발생합니다!

class Study {
    private Book book;

    public Study(){
        book = new Book(10, "3만원");
  }
}

위의 코드처럼 Book의 생성자가 바뀐다고 가정하면, new로 생성할 경우에는 Study의 생성자에서도 코드 변경의 귀찮음이 발생하게 됩니다..ㅜ

이렇게 Study라는 클래스 내부에서 객체를 생성하고 관리하게 되면, 추후 발생하는 변화에 유동적으로 대응할 수 없는 문제가 발생합니다!

그렇기 때문에 DI Dependency Injection이라는 기능을 통해 외부로 부터 주입받아서 결합도를 낮추고 변화에 능동적으로 대처하도록 구현해야 합니다.

필드주입과 생성자 주입 그리고 Setter 주입

필드주입보다 생성자 주입이 좋다고 다들 말하지만, 실제로 왜 좋은지에 대해 고민해본적이 없던것 같습니다. 더불어 지금은 사용하지 않는 Setter 주입에 대해서 살펴보겠습니다!

public class Study {

    @Autowired
    private Book book;
}

아마 많은 교재에서 필드 주입을 통해 인스턴스를 할당할 것입니다,,, 인텔리제이를 사용하신다면, 필드주입 부분에서 에러를 확인하실 수 있는데 필드주입은 현재 스프링 또는 자바 어플리케이션에서 권고하지 않는 방식입니다.

필드를 선언하고 필드 위에 @Autowired를 선언하면, 외부 의존성 주입을 받지 않고 인스턴스를 생성하여 Bean에 등록할 수 있습니다. 이방식은 코드가 간결한 장점이 있지만! Test를 작성할때 외부주입이 불가능함으로 어려움을 겪을 수 있습니다. 더불어 추상체가 아닌 구현체를 직접 생성하기 때문에 변화에 민감해집니다.

생성자 주입은 아래와 같이 외부의 주입을 통해 의존관계를 형성하는 방법입니다!

public class Study {

    private final Book book;

  public Study(Book book){
        this.book = book;
  }
}

외부로 부터 주입 받기 때문에 변화에 능동적으로 대처할 수 있고, 구현체에 의존하지 않고 사용할 수 있는 장점이 있습니다!

더불어 final로 생성된 불변객체를 사용함으로서, 인스턴스의 복제, 비교가 쉬워지며, 한번 생성한 인스턴스에 대한 변경을 금지시킴으로서 안전한 객체사용이 가능해집니다!

Setter 주입은 set() 메서드를 통해 생성자를 주입하는 방법입니다

public class Study{
    private Book book;

    @Autowired
    public void setBook(Book book){
        this.book = book;
  }
}

선택적으로 book에 대한 인스턴스를 주입받아 생성할 수 있도록 구현하는 방식입니다!

물론, 해당 방식을 사용하면, 원하는 인스턴스를 개발자가 원하는 시기에 생성할 수 있고 관리할 수 있다는 장점이 존재합니다!

하지만! 이 방식의 경우 Study객체의 인스턴스가 생성되었을 때 set()을 돌려주지 않으면 book이 null값을 가져 exception이 터질 수 있습니다!

런타임시에 문제를 해결할 수 없기 때문에 해당 주입 방법은 지양하는 것을 추천드립니다!

다음으로 interface를 통해 확장성을 가지는 예를 살펴보겠습니다!

class Study {
    private final Book book;

    public Study(Book book){
        this.book = smallBook;
  }
}

SmallBook이라는 Book을 implements한 클래스가 있다고 가정합시다!

Study에서는 Book이라는 존재만 알고 있어도 smallBook이라는 구현체를 받아서 사용할 수 있게 됩니다!

Book smallBook = new SmallBook();
new Study(smallBook);

반대로 직접 인스턴스를 생성할 경우!

class Study {
    private final Book book;

    public Study(){
        this.book = new SmallBook();
  }
}

Study는 book을 implements한 모든 구현체를 직접 Study안에서 수정해야 하는 불편함을 겪게 됩니다..

이처럼 Study가 구현체에 의존하게 된다면, Book이라는 인터페이스를 implements한 모든 class에 대한 생성자 혹은 변환 메서드를 구현해야 하는 불편함이 발생합니다!

그렇기 때문에 우리가 자주 외웠던 SOLID의 마지막 원칙 DIP Dependency Inversion principle 의존성 역전 원칙를 통해 구현체 직접 의존하지 않고, 추상화된 클래스를 의존함으로서 변경에 유용하고 다형성을 통한 확장을 유용하게 할 수 있는 코드를 작성해야 합니다!

DIP의 개념이 쓰이는 곳은 정말 방대합니다. 예를 들어 Spring에서 OAuth2.0을 통해 로그인을 진행한다고 하면

이렇게 다양한 소셜네트워크 서비스가 존재할 것입니다. 만약 해당 객체들을 서로 다른 클래스로 구현한다면

public class KaKao{

}

public class Facebook{

}

public class Naver{

}

이렇게 무지막지한 class 생성 폭발이 발생할 겁니다! 그리고 이를 service에서 사용하게 된다면

public void loginkakao(){
    kakao.login();
}

public void loginNaver(){
    naver.login();
}

public void loginFacebook(){
    facebook.login();
}

다형성이라는 개념은 어디에도 없게 되고, 코드의 길이는 점점 길어지며, login을 진행하기 위해서 필요한 서비스 로직은 방대해지게 됩니다..

그렇기 때문에 카카오, 페이스북, 네이버 모두 로그인이라는 인터페이스를 상속받아서 사용하게 된다면 추후 로그인 로직에서 다형성을 지킬 수 있으며, 구현체에 의존하지 않는 코드를 작성할 수 있게 됩니다.

결국, 인터페이스를 통해 선언된 로직을 통해 카카오, 페이스북, 네이버에 의존하지 않고도 로그인 서비스를 이용할 수 있게 되는 것입니다.

public interface Login(){
    void login();
}

public class KaKao implements Login{

}

public class Facebook implements Login{

}

public class Naver implements Login{

}

public void login(){
    login.login();
}

지금까지 간단한 예제를 살펴보며, DI와 DIP에 대해 간략하게 살펴봤습니다!

DI에 대해 다시 정리하자면..

아마도 위의 예제 코드를 보더라도 많이 어려움을 느낄 것 같습니다.. 그래서 탕수육으로 비교하며 DI에 대한 정리를 마칠려고 합니다!

부먹 탕수육은 소스가 이미 부어져 있어서 새로운 소스가 나타났을때, 기존의 소스를 제거하기 위해 많은 어려움이 존재할 것입니다..ㅜㅜ

하지만 찍먹 탕수육의 경우에는 새로운 소스가 나타난다면, 언제든지 새로운 소스를 찍어먹으며 다채로운 맛을 느낄 수 있을 겁니다!!

마찬가지로 DI도 외부로부터 주입받음으로써, 내부의 로직 변경없이, 변경된 클래스에 대한 설정만으로도 문제를 해결할 수 있는 장점을 제공합니다!

그렇다면 DIP는?

DIP는 치킨집에서 제일 잘나가는 치킨을 무엇이냐고 물어보는 것과 같다고 생각합니다.

우리가 치킨집에 가서 제일 잘팔리는 치킨을 달라고 하면, 종업원은 다양한 치킨메뉴 중 어떤 것을 시킬거냐고 물어볼 것입니다.

만약 우리가, 후라이드 치킨을 시켰다면, 그 가게에서 제일 잘팔리는 양념치킨을 못먹었을 겁니다...

마찬가지로 DIP는 치킨처럼 큰 범주를 가진 인터페이스를 통해서 양념치킨과 후라이드치킨과 같은 구상체를 받을 수 있는 원칙입니다.

이를 통해 우리는 치킨이 양념치킨 또는 후라이드치킨처럼 종류가 다양해지는 다형성이라는 기능을 살릴 수 있게 됩니다.

URI, URL, URN에 대해서 고민해 본적이 없던 것 같습니다.. 이번 기회에 세가지의 차이점에 대해 정리해보겠습니다!

URI

uniform resource identifier의 약자로서 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있는 시통합 자원 식별자를 의미합니다!

이런 고유한 주소를 가진 식별자를 URI라고 합니다!

• 클라이언트가 서버의 특정 리소스를 요청한다고 하면! http://www.donggeon.com/donggeon/home.jpg 이것이 URI 입니당!
• URI는 URL과 URN을 포괄하는 큰 범주의 식별자를 의미합니다!
  • 결론적으로 고유한 식별자를 나타내주는 기술로 URL과 URN이 존재합니다!

URL

uniform resource locator의 약자로서 특정 서버의 한 리소스에 대한 구체적인 위치를 제공합니다! 리소스가 어디에 있고, 어떻게 접근해야 되는지 알려주며 리소스를 식별하는 역할을 합니다!

• URL의 구조

  • 스킴://서버위치/경로

• 리소스

  • 웹에서 식별할 수 있는 모든 자원을 의미

• 스킴 scheme

  • 리소스에 접근하기 위해 사용되는 프로토콜을 서술!
  • http

• 서버위치 서버의 인터넷 주소

  • 서버의 위치, 웹 클라이언트가 리소스가 어디에 호스팅 되어 있는지 알려줍니다!
  • www.donggeon.com

• 경로 웹 서버의 리소스

  • 서버에 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지 알려줍니다!
  • /donggeon/home.jpg

• URL이 가져온 평화

URL을 사용하기 전에는 각각의 애플리케이션이 가지고 있는 분류방식에 맞추어 접속해야 했고, 원하는 정보를 얻기 위해서 해당 애플리케이션의 접근 방법을 알아야 하는 불편함이 존재했습니다.!! 하지만, URL을 통해서 획일화된 접근 방법으로 이전과 다르게 쉽고 빠른 접근이 가능해졌습니다!

• URL 문법
  • URL을 구성하는데 쓰이는 체계 스킴://사용자이름:비밀번호@호스트:포트/경로;파라미터?질의#프래그먼트

• 단축 URL == 상대 URL
  • 리소스 안에 있는 리소스를 간결하게 기술하는데 사용하며, URL 일부를 입력하면 자동으로 완성!

상대 URL과 절대 URL

• 상대 URL
  • URL을 짧게 표기하는 방식
  • 모든 정보를 갖고 있지 않음!
  • 필요한 정보를 얻기 위해 기저base라고 하는 다른 URL을 사용해야 함!
    • 기저 URL은 리소스에 명시적으로 제공되며 포함되고 있는 URL을 의미합니다!
    • 기저 URL이 없다면, 보통 절대 URL로 구성되어 있는다는 것을 의미하지만, 불완전하거나 깨진 URL일 수 도 있습니다!
• 절대 URL
  • 리스소에 접근하는데 필요한 모든 정보를 가짐

URL 확장

사용자가 URL을 빠르게 입력하도록 도와주는 기능!

• 호스트 명 확장

  • 단순한 휴리스틱만을 사용해서 입력한 호스트 명을 전체 호스트명으로 확장
  • naver을 입력하면 -> www.naver.com으로 확장!

• 히스토리 확장

  • 과거에 사용자가 방문했던 URL의 기록을 저장해 놓기!
  • www.na만 입력해도 이전 기록을 찾아서 www.naver.com을 만들어줌!

  ---

안전하지 않은 문자

정보의 유실을 방지하기 위해서 특정 문자를 제외시키고 알파벳을 통해 URL을 구성하도록 한것!

그러다 보니, 특정 문자를 사용해야 할때 어떻게 진행해야 될지 문제가 발생하였고!

이것을 해결하기 위해 이스케이프라는 기능이 추가되었음!!

• 이스케이프

  • 안전하지 않은 문자 알파벳을 제외한 문자들를 알파벳 유형으로 인코딩해서 URL을 구성!
  • 이스케이프를 통해 특정 문자나 데이터를 인코딩할 수 있게 되어 이동성과 완성도가 UP!

• 인코딩 체계

  • 안전하지 않은 문자를 % 기호를 통해 아스키 코드로 표현!

안전하지 않은 문자 자체를 URL에 기입하여 사용할 수 있다.. 하지만 어플리케이션을 구성할 때 제일 중요한 것은 약속된 정해진 내용을 기반으로 구현해야 된다는 것이다!

기존에 약속된 내용을 부시고, 독자적인 구성을 진행한다면 어플리케이션의 오류 또는 오작동을 일으킬 수 있기 때문이다!

URN

uniform resource name의 약자로서, 콘텐츠를 이루는 리소스의 위치에 영향 받지 않는 유일무이한 이름 역할을 합니다!

• 위치 독립성

리소스를 옳기더라도 독립적인 유일무이한 위치를 제공합니다!, 단 리소스가 해당 URN을 변경하지 않는다는 가정하에요! 현재 그 리소스가 어디에 존재하든 상관없이 이름만으로 리소스를 식별할 수 있습니다!

• URL -> URN으로

URL의 가장 큰 문제점은 가르키고 있는 리소스가 옮겨지면 기존에 사용하던 URL은 더 이상 사용 불가하다는 것이다! 객체의 위치와 상관없이 절대적으로 사용가능한 기술이 URN이다! URN으로 바꾸려고 변화를 꾀하지만, 방대한 웹 생태계에서 URL 기술을 대체하기까지 아직 많은 시간이 걸린다!

마치며

지금까지 단순하게 URL이라고 칭했던 정보 제공 데이터에 대해 학습할 수 있는 기회가 되었습니다. URI가 URL과 URN을 감싸안는 집합이며, URL과 URN이 리소스의 상대적 혹은 절대적 주소에 따라 차이점이 존재함을 알게 되었고, 더불어 현재 우리가 쓰고 있는 주소체계는 대부분 URL임을 확인하게 되었습니다!

URL이 가지고 있는 규칙과 스킴, 서버위치, 경로 등의 기본적인 쳬계와 더불어 기타 다양한 구조를 학습할 수 있었습니다! 생각보다 많은 정보와 기능을 가질 수 있는 것을 알게 되었고, 이를 활용하여 다양한 어플리케이션에서 유용하게 쓰일 수 있음을 배웠습니다!

마지막으로 URL이 리소스에 의존적이어서 리소스의 위치가 변경되면 기존 URL로 데이터를 찾을 수 없는 단점을 알게 되었고, 이를 해결하기 위해 나온 URN이라는 절대적 주소 기술 체계에 대해 알게 되었습니당!

추상 팩토리 패턴이란?

Abstract Factory Pattern은 구체적인 클래스에 의존하지 않고 서로 연관된 객체들의 조합을 만드는 인터페이스를 제공하는 패턴입니다! 다양한 구성 요소 별로 객체의 집합을 생성해야 할 때 유용

• 추상 팩토리 팩토리 패턴은 관련 있는 객체를 묶어서 만들고, 조건에 맞추어 각각의 객체를 생성할 수 있는 패턴입니다! 팩토리 메서드와 유사하지만, 한층 더 추상화화여 사용하는 방법입니다!!

• 팩토리 패턴과 다르게 추상 클래스에 의존하는 구상 클래스를 생성하지 않아도 인스턴스를 생성할 수 있는 장점이 있습니다! 서로 다른 객체들을 하나의 공장에서 관리함으로써 생성할 수 있는 장점이 있습니다!!

추상 팩토리 다이어그램입니다!

charger

public interface Charger {
    String message = "충전기 생성";
}

public class LgCharger implements Charger {
    public LgCharger() {
        System.out.println(Brand.LG + message);
    }
}

public class AppleCharger implements Charger {
    public AppleCharger() {
        System.out.println(Brand.APPLE + message);
    }
}

• charger interfact를 통해 lg와 apple charger를 하나로 묶었습니다!!
• 공통된 부분이 많은 것 같아서 이점은 다시 수정해보려고 합니다!

laptop

public interface Laptop {
    String message = "노트북 생성";
}

public class LgLaptop implements Laptop {

    public LgLaptop() {
        System.out.println(Brand.LG + message);
    }
}

public class AppleLaptop implements Laptop {

    public AppleLaptop() {
        System.out.println(Brand.APPLE + message);
    }
}

• laptop도 charger와 마찬가지로 묶어서 만들었습니다!!
• 학습을 진행하기 위한 예제로 사용하려다 보니 부족한게 많은 것 같습니다....ㅜㅜ

ProductFactory

public interface ProductFactory {
    Laptop createLaptop();

    Charger createCharger();
}

lgProductFactory

public class LgProductFactory implements ProductFactory {
    @Override
    public Laptop createLaptop() {
        return new LgLaptop();
    }

    @Override
    public Charger createCharger() {
        return new LgCharger();
    }
}

• Factory를 통해서 LG 상품을 하나로 묶어 생성할 수 있도록 구현했습니다!

appleProductFactory

public class AppleProductFactory implements ProductFactory {
    @Override
    public AppleLaptop createLaptop() {
        return new AppleLaptop();
    }

    @Override
    public AppleCharger createCharger() {
        return new AppleCharger();
    }
}

• lg Factory와 마찬가지로 묶어서 만들었습니다!!
• 추상 팩토리 패턴을 활용하니 더 쉽고 알아볼 수 있는 코드를 구현할 수 있게 된 것 같습니다
• 다만 아직 초보자라 구현하는데 많은 시간이 걸린 것 같습니다...ㅜㅜㅜ

BrandFacotry

public class BrandFactory {
    public void createProduct(String brandName) {
        Brand brand = Brand.findByBrand(brandName);
        ProductFactory productFactory = choiceFactory(brand);
        createParts(productFactory);
    }

    private ProductFactory choiceFactory(Brand brand) {
        if (brand == Brand.LG) {
            return new LgProductFactory();
        }
        return new AppleProductFactory();
    }

    private void createParts(ProductFactory productFactory) {
        productFactory.createLaptop();
        productFactory.createCharger();
    }
}

• BrandFactory를 통해 알맞은 brand를 찾고, 그 브랜드의 하위 메서드를 생성할 수 있도록 구현했습니다!!

Brand

public enum Brand {

    LG("엘지"),
    APPLE("애플");

    private final String brand;

    Brand(final String brand) {
        this.brand = brand;
    }

    private static final String BRAND_SEARCH_ERROR_MESSAGE = "브랜드명이 잘못된 입력입니다.";

    public static Brand findByBrand(String inputBrand) {
        return Arrays.stream(Brand.values())
                .filter(b -> b.brand.equals(inputBrand))
                .findAny()
                .orElseThrow(() -> new IllegalArgumentException(BRAND_SEARCH_ERROR_MESSAGE));
    }

}

• Enum class는 예제에서 딱히 사용을 안하시는 것 같은데,,, 저는 이게 편리해서 사용해봤습니다!

마치며

• 위키피디아에서 본 클래스 다이어그램과 구글링을 통해 여러 예제를 본 것 같습니다. 실제로 추상 팩토리 패턴을 사용해서 예제를 학습하다보니, interface로 묶어주고 또 묶어준 것을 한번 더 묶어줌으로서 이후 로직이 간단하고 가시성이 높아짐을 확인하게 되었습니다!!
• 아직 예제 코드에서 수정할 부분이 많아서 추후 조금씩 수정하고 업로드하겠습니다!

GoF - Design Pattern

Gang of Four 4명의 개발자가 합심하여 모두가 쉽고 빠른 개발을 위해 만든 소프트웨어 디자인 패턴이다!

디자인 패턴을 통해 더 쉽고 빠른 개발을 진행할 수 있습니다!

하지만,,, 실제로 어떻게 동작하는지 자세히 모르기 때문에 이번 기회에 하나씩 알아보도록 하겠습니다!

생성 패턴

1. Abstract Factory
2. Builder
3. Factory Method
4. Prototype
5. Singleton

구조 패턴

6. Adapter
7. Bridge
8. Composite
9. Decorator
10. Facade
11. Flyweight
12. Proxy

행위 패턴

13. Chain of Responsibility
14. Command
15. Interpreter
16. Iterator
17. Mediator
18. Memento
19. Observer
20. State
21. Strategy
22. Template Method
23. Visitor

😱 이번에는?

• Object(객체) 탐구하기 - toString(), equals(), hashCode() 언제 쓰이는지!!

🛒 들어가면서

• 프로젝트를 진행하다보면, 항상 toString(), equals(), hashCode()를 어떻게 재정의할지 고민합니다..
• 그러다 보니까 Lombok에서 지원하는 @EqualsAndHashCode @ToString을 사용하는 것 같습니다..ㅜㅜ
• 이펙티브 자바와 클린코드 책을 읽으면서, 어노테이션을 최소화하고, 개발자가 직접 작성하는 방향이 좋다고 배우게 된 것 같습니다.
  • 필요없는 코드가 자동 생성되는 것을 방지하기 위해서 라고 학습했습니다!
• 무엇이 좋은지, 그리고 @Override를 어떻게 해야될지 고민했던 것 같습니다,,
• 이번 기회에 Object Class에 있는 method를 어떻게 사용할지에 대해 작성하도록 하겠습니당!!!~~

😆 Object Class란?

• 자바 클래스의 최최최고 조상 클래스입니다!!!

  모든 클래스는 Object 클래스를 상속받고 있습니다! 우리가 따로 extends하지 않더라도 기본으로 상속을 제공합니다!!

• java.lang pakage에 속하며, 자바의 가장 기본적인 동작들을 수행합니다!

  그렇기 때문에 별다른 import 없이 사용 가능해요~~

🖊 toString()

• toString은 기본적으로 해당 인스턴스의 대한 정보를 문자열로 반환합니다!

  기본적으로 toString을 쓰게 되면! 아래와 같이 참조된 정보를 출력하게 됩니다!! 사용자가 원하는 값을 출력하기 위해서는 재정의가 필요합니다!

DongGeon dongGeon = new DongGeon();
System.out.println(dongGeon);

>> DongGeon@1233123C

• Lombok을 이용하게 되면서 toString을 조금 더 편하게 사용할 수 있습니다!

  Lombok을 사용하면, 정말 편리하게 toString을 이용할 수 있지만! 모든 데이터가 같이 출력되기 때문에 필요 없는 데이터도 같이 출력되게 됩니다 ㅜㅜ

  @ToString
  public Class DongGeon {
    private int age;
    private String name;
  
    public DongGeon(int age, String name){
        this.age = age;
        this.name = name;
    }
  }
  

DongGeon dongGeon = new DongGeon(25, "김동건"); System.out.println(dongGeon);

DongGeon(age=25, name=김동건)

- toString을 재정의 하는 이유!
1. 객체가 가진 정보를 조금 더 가독성 있게 보이기 위하여!
2. 개발자가 원하는 정보를 출력하도록 변경할 필요가 있다!!

public Class DongGeon { private int age; private String name;

public DongGeon(int age, String name){
    this.age = age;
    this.name = name;
}

@Override
public String toString() {
    return "나는 " + name + "이고, 나이는 " + age + "이다";
}

}

DongGeon dongGeon = new DongGeon(25, "김동건"); System.out.println(dongGeon);

나는 동건이고, 나이는 25이다

<br>

### 🥳 equals()
> 각 인스턴스가 동일한 인스턴스인지 비교합니다! 내용이 같은지, 주소가 같은지 확인할 수 있지만, `==` 대신 equals를 쓰는 이유는 재정의가 가능하기 때문입니다! 그리고 참조형 필드를 비교하기 위해서도요!


- 동일성과 동등성
> 비슷하겠지만, 동일성은 오브젝트가 완전히 같은지를 의미합니다
> 동등성은 같은 정보를 내포가 있는지를 의미합니다!!

DongGeon donggeon1 = new DongGeon(25, "김동건"); DongGeon donggeon2 = new DongGeon(25, "김동건");

boolean checkOne = donggeon1 == donggeon2; boolean checkTwo = donggeon1.equals(donggeon2);

- `==` 연산을 사용할 경우 원시타입의 경우에는 값을 비교합니다! 정황상 donggeon1과 donggeon2는 같은 값을 가지고 있지만!!서로 다른 주소이기 때문에 `false`가 리턴되게 됩니다 ㅜㅠㅜ

- 반대로 `equals`연산을 사용하게 되면 재정의하여 equals가 가진 기본 성능을 바꿀 수 있다!
    + Object Class를 까보면, equals는 기본적으로 `==` 연산을 하고 있다!

public boolean equals(Object obj) {
    return (this == obj);
}

- 기본으로 제공되는 equals 연산자는 결국 `==`와 같은 기능을 제공한댜.... 그렇기 때문에 @Override를 통해 우리의 코드에 맞는 equals를 재정의해야 합니당!

@Override public boolean equals(Object object) { if (!(object instanceof this)) { return false; } return this.equals(object); }

- 위의 코드처럼 `instanceof` 연산자를 통해 재정의하면 더욱  equals의 기능을 극대화시킬 수 있다!




### 😩 hashCode()
> hashCode는 객체를 식별할 수 있는 정수 값을 의미합니다! hashCode를 통해 저장된 데이터를 더 빠르게 조회할 수 있습니다!

- `hashCode()`는 원래 사용자가 직접 재정의해줘서 구해줘야 합니다!! ㅜㅜ
     하지만 각 IDE가 재정의해주는 hashCode가 정말 좋게 구현되어 있기 때문에 이점은 PASS~

- `hashCode`를 재정의함으로써 HashTable에 HashCode가 최적화되어 삽입될 수 있는 장점이 있습니다!
    + 하지만, ,.,, hashCode를 재정의하면서 나오는 불편함...크름...

@Override
public int hashCode() {
    if (this == null) {
        return 0;
    }
    return this.hashCode();
}

```

• 저의 경우에도 hashCode를 직접 재정의해서 구하기 보다는 IDE 또는 LOMBOK에서 만들어주는 hashCode를 사용하고 있습니다!

🎲 결론

toString(), hashCode(), toString() 모두 재정의하여 개발자가 원하는 값을 반환하도록, 혹은 내부 로직을 변경함으로써 원하는 기능을 제공하도록 수정하는 것이 좋다고 생각합니다!

다만!! 우리에게는 LOMBOK이 있고 편리한 TOOL이 너무나 많습니다 ㅜㅜ

모든 것을 재정의하고 모든 부분에서 어노테이션 없이 사용하기에는 아직 초보(예비)개발자가 하기에 너무나 > 큰 부담이 되는 것 같습니다..ㅜㅜㅜ

그렇기 때문에, 일단 어노테이션을 작성해서 개발을 하다가, 리펙토링을 하며, 하나씩 어노테이션을 지우고 직접 구현해 나가는 방향도 저는 좋다고 생각합니다... 물론 지극히 개인적인 의견입니다!!

😱 이번에는?

• StringBuilder와 StringBuffer는 무슨 차이 입니다!

🛒 들어가면서

• JAVA에서 문자를 다룰 수 있는 기술을 다양하게 존재합니다! 그중에서 String, StringBuffer, StringBuilder가 가장 많이 사용되는 방법이라고 생각합니당.
• 각각의 기능들은 비슷한 기능을 제공하지만, 실제로 안을 보면 사뭇 다름을 알 수 있어요!
• String, StringBuffer, StringBuilder를 하나씩 풀어나가며 이번 과제를 진행하겠습니당당당!!

😆 불변 객체와 가변 객체

1. 불변 객체
   • 불변 객체 immutable object는 생성 후 그 상태를 바꿀 수 없는 객체
   • 불변 객체는 String, Integer, Boolean과 같은 Class도 있지만, 사용자가 직접 final로 원시타입을 생성하여 불변 객체를 만들 수 있습니다!

    public class Person {
        private final String name;
        private final int age;

        public Person(String name, int age){
            this.name = name;
            this.age = age;
        }
    }

2. 가변 객체
   • 가변 객체 mutable object는 생성 후에도 상태를 변경할 수 있는 개체
   • int, char, boolean 등 원시타입 필드를 가진 클래스는 가변 객체입니다!
   • 하지만, 원시타입 필드에 final을 붙여서 불변 객체로 만들 수도 있습니다.

    public class Person {
        private String name;
        private int age;

        public Person(String name, int age){
            this.name = name;
            this.age = age;
        }
    }

🖊String

처음 알고리즘 문제를 풀었을 때, 항상 String을 사용했던 것 같습니다! 그런데 어느 순간부터 String을 사용한 연산을 하면, 메모리를 너무 많이 잡아먹어 문제를 해결하지 못했던 것 같아요..ㅜㅜㅜ

1. String은 무엇인가?

• String은 원시 타입이 아닙니다!
• 문자열을 가진 객체입니다!

2. String은 불변 객체입니다!

• 가변 객체와 다르게 한번 생성하면 그 값을 바꿀 수 없습니다!
  • 하지만, 재할당은 가능합니다!

3. String을 생성하는 방법!

   String index = new String("예시");
   String index = "예시";

4. String이 제공하는 Method

   equals
   indexOf
   replaceAll
   substring
   toUpperCase

결국, 불변객체를 사용해야 하는 경우 String을 사용하는 것은 좋지만, 값이 계속 바뀌는 상황일 경우에는 지양하는 것이 좋다!

🥳 StringBuffer

처음 무작정 코딩테스트를 위해 StringBuffer를 사용했던 경험이 있습니다. 면접때 면접관님이 StringBuffer를 사용한 이유와 StringBuilder와의 차이점을 물으셨지만.. 결국 완벽한 답을 하지 못한 경험이 있습니다.

• String과 다르게 StringBuffer는 가변 객체입니다!
• 기존에 할방받은 공간에 새로운 데이터가 쌓이고, 추가 데이터가 공간보다 커지게 되면, 기존의 버퍼 크기를 늘립니다!!
• StringBuffer는 동기화 Synchronized를 지원합니다!
  • 여러 스레드가 하나의 자원을 사용하려고 할때 다른 스레드의 접근을 막는 것이 동기화 입니다!!
  • 동기화를 지원하기 때문에 StringBuffer는 멀티스레드 환경에 쓰입니다!
    • 물론 멀티스레드 환경이 아니더라도 사용할 수 있지만, 그럴 경우에는 StringBuilder가 더 효율적입니다.
  • 동기화를 지원하는 `StringBuffer"는 멀티스레드 환경에서 안전하게 자원을 사용할 수 있음을 보장합니다!!

😩 StringBuilder

알고리즘 문제를 풀때, StringBuffer보다 StringBuilder가 더 빠르다는 말을 들었습니다. 혹해서 아직까지 StringBuilder를 가끔 사용하고 있는 것 같습니다. 이번 기회에 StringBuilder를 탐구하겠습니당!!

• StringBuilder도 StringBuffer와 마찬가지로 가변 객체입니다!
• 하지만 동기화를 지원하지 않는 다는 가장 큰 차이점이 존재합니다!
• 동기화를 지원하지 않는 StringBuilder를 사용하는 가장 큰 이유는
  • StringBuffer보다 단일 스레드 환경에서 빠른 속도를 보여주기 때문입니다!

🎲 결론

String은 불변 객체이고, StringBuffer와 StringBuilder는 가변 객체이다

단일 스레드 환경에서 StringBuilder는 제일 좋은 성능을 발휘한다.

StringBuffer는 Synchronized를 지원하지만, StringBuilder는 지원하지 않는다.

StringBuffer는 멀티 스레드 환경에서 안정성 보장한다.

상황에 맞추어 StringBuffer와 StringBuilder를 사용해야 하며, 무엇이 좋은지는 그 상환이 판단한다.

간혹, String이 StringBuffer와 StringBuilder보다 좋은 성능을 보일 떄 도 있다!

📚 Reference

• 점프 투 자바

😣 Coding Convention!

프로그래밍을 하다보면, 협업을 위해 팀 또는 회사가 규칙을 정해서 Coding Rule를 만듭니다!

일종의 규칙이자, 관례 그리고 법이라고 생각합니다! 이번에는 Coding Convention에 대해 다뤄보려고 합니다!!

🕓Naming Rule

Class의 경우에는! 각 단어의 앞글자를 대문자로 사용합니다!

class MyClass // o
class myclass // x

그리고, 클래스는 대게 특정한 오브젝트를 이름으로 가집니다!

method의 경우에는! 첫 단어의 앞글자는 소문자이고, 다음 글자의 앞글자는 대문자입니다!

void helloDongGeon // o
void HelloDongGeon // x

method는 메세지를 던져주는 역할을 합니다! 그러다 보니 class와 다르게 동사형을 사용합니다! ~~하다 라는 의미를 갖는 이름을 가지도록 명칭을 지어주어야 합니당당

field명은 method와 비슷합니다! 하지만! class와 마찬가지로 특정한 오브젝트를 이름으로 가집니다!

int human = 3; // o
int run = 4; // x

🕒 Reference

java에서는 모든 것이 레펀스 값입니다!! <-- 곰튀김님께서 해주신 말씀!

자바의 타입에서는 원시값과 박싱된 값이 있는데,,,

원시값은

boolean, byte, int, short, long, float, double, char이 있습니다!!

우리가 자주쓰는 String은 원시값이 아닙니다!! 이것에 대해서는 다음 Chapter에서 작성하겠습니당!

Call By Value : 값에 의한 호출

원래의 데이터를 복사해서 처리하기 때문에 원본 값을 보존할 수 있다!

Call By Refernece : 참조에 의한 호출

원래 데이터를 직접 참조하여 사용하기 때문에 공유해서 쓰는 방법이다!, 원본 값을 사용하기 때문에 원래 값에 영향을 미칠 수 있다!

🕒 Constant Pool

public void talk() {
    String convention = "";
    for(int i=0; i < 10; i++){
        convention += "a";
    }
}

위의 코드처럼 String 객체에 += 연산을 진행할 경우 이미 메모리에 상주한 값을 바꾸는게 아니라, 새로운 데이터를 메모리에 생성하게 됩니다!! 결국!! 이와 같은 로직이 있다면 메모리가 폭발!!

🕑 Object

모든 객체의 최상위 객체는 Object 입니다!!

public class People extends Object

모든 클래스에서 Object 최상위 클래스는 자동적으로 extends되어 집니다~~

그렇기 때문에 Object class에서 사용되는 메서드를 @Override해서 쓸 수 있어요~

😱 첫 기록인 만큼 왜 시작했는지

TIL이라는 것을 알긴 했지만, 스스로?가 납득할 정도로만 작성했던 것 같습니다.

단순하게 체크리스트?처럼 작성해서 기록하고 공부했던 것 같아요 물론 TIL이 남들에게 보여지기 위해서 작성하는 것은 아니지만, 어느 정도 나를 정리할 수 있는 공간은 아니었습니다. 그렇기 때문에! 이제부터 TIL을 통해 조금씩 정리해보려고 합니다!!!!🥰🥰

😝 처음이라 아직 어려워요

정말 정말 정말 좋은 기회로 프로그래머스 백엔드 데브코스 백엔드 과정을 수강하게 되었습니다!!🙏🙏🙏 자바 언어와 스프링 프레임워크를 어느정도 학습한 시점에서 스스로 기본기가 부족하다고 느꼈고 지원하게 했습니다. 아직 어려운 내용을 학습하지는 않아서 그래도 무난하게 따라가고 있습니다!! 하지만.,,,

😜 조금 어려웠던거?

수업 내용을 따라가기에 어렵다고 느낀 적은 없습니다.. 그런데 가장 어려웠던 것은 프로그램의 전반적인 시스템?을 이해하는 부분인 것 같습니다. 워낙 방대하고, 큰 규모를 자랑하다 보니... 어느 정도 시스템을 이해하는데 시간이 걸렸던 것 같습니다! 아직 완벽하게 이해하지 않았지만, 차근차근 프로그래머스 교육 시스템에 녹아들도록 노력하려고 합니다~~🌱🌱

📚 그래서 오늘 공부를 뭐했지?

오늘 주된 학습은 크게 4가지인 것 같습니다

1. 프로그래머스 교육 시스템 파악하기

2. 인터페이스 학습하기!

3. Spring-Security

4. TIL 작성하기!!!

   
   ### 📣📣 차근차근 하나씩 정리하겠습니다! 📣📣

🕐 프로그래머스 교육 시스템 파악하기

저번 주 금요일 프로그래머스 백엔드 과정의 전반적인 기둥이신 스펜서 님께서 시스템에 대해 자세히 설명해주셨습니다.

그런데... 막상 스스로 해보려고 하니 이게 뭐지?라고 계속 갸우뚱한 것 같습니다.

직접 부딪혀보지 않으면 모른다는 말이 이것을 말하는구나 생각 들었습니다.

그래도 스펜서 님께서 정리해주신 노션 정보와 공지사항을 통해 드디어 대략적인 시스템 구조를 90% 정도 알게 된 것 같습니다!!!! 🙌🙌🙌

감사합니당 감사합니당~

🕑 인터페이스 학습하기

아마도 자바 개발자에게 있어 인터페이스는 핵심 요소라고 생각합니다

인터페이스를 통해 기능을 확장시킬 수도 있고, 반대로 규제할 수 있어 없어서는 아니될 최고의 아이템입니다!!

그렇기 때문에 인터페이스를 학습했던 내용은 조금 더 다듬어서 TIL 남기겠습니다!!

ps. 강의를 들으면서, 객체지향을 대입해서 인터페이스에 대해 쉽고 빠르게 알려주는 강의는 처음입니다. 처음부터 이 방식으로 배웠다면, 아마 지금 저는 자바 왕이 되었을 것 같습니다...😹😹

🕒 Spring-Security

Okky를 통해 만난 동갑내기 삼인방이 있습니다!! 다들 객체지향과 웹에 대해 관심이 있었고, 현재 물물교환을 주제로 하는 토이 프로젝트를 진행하고 있습니다!

저는 해당 토이 프로젝트에서 Member Domain을 맡아서 구현하고 있습니다!

사실 지난 화요일에 노트북이 과도한 업무로 사망해서 포맷하느라,,, 기존 데이터를 날리느라 애써 구현했던 소스를.,,, 잃어버리게 되었습니다..ㅜㅜㅜ 깃에 커밋을 한다는 것을 push를 하지 못해서 날리게 되었습니다..

한번 날리게 되니까 커밋 후 바로 push 하는 습관이 든 것 같습니다 📢📢📢📢

유림님이 선물해주신 인프런 강의를 들으며 깃에 대한 완벽한 학습을 진행해야 될 것 같습니다!

오늘 가장 오래 고민 했던 내용은 Security가 보관하고 있을 객체를 어떻게 관리할까 였습니다,.,

레포지터리에서 뺴온 데이터를 DTO로 가공할 것인지, 아니면 레 포지터에서 조회할 때부터 다른 DTO를 사용할 것인지 고민했던 것 같습니다.. 이 부분에 대해서 4시간 넘게 고민했지만, 어떤 코드가 좋을지 모르겠어서.,,, 팀원들과 한번 상의하기로 했습니다!!

또또또

아직 회원가입과 로그인만 구현했는데.... 겁나기 시작합니다.. 두렵기 시작합니다.. 무섭기 시작합니다...ㅜㅜㅜㅜ

아직 끝이 보이지는 않지만, 열심히 공부하다 보면 언제가 끝이 보이지 않을까 소망합니다

🕓 TIL 작성하기!!!

저는 TIL을 작성하는 게 처음이라 많이 어색하고 어려운 것 같습니다..

죽여,,줘... 지금도 이 글을 작성하기까지 지우고, 쓰고, 지우고, 쓰고를 무한 반복하고 있습니다..ㅜㅜㅜㅜ🤒🤒🤒

아직 어떻게 작성해야 하는지, 그리고 무엇을 중점으로 두어야 하는지 감이 잡히지 않지만! 계속 계속 도전하겠습니당당

📫 마치며

TIL을 쓰려고 했는데.. 다시 읽어보니 회고가 된 것 같습니다.ㅜㅜㅜㅜ 반성 반성

스펜서 님께서 예쁘게 작성해주신 공지를 읽으며, 인터페이스 부분을 다시 작성해야겠습니다!!

벌써 이 글을 작성하고 있는 시간은 오전 2시 50분!!

쓰다 보니 두서가 없고, 괜스레 핵심이 없는 것 같아 아쉬움이 남습니다ㅜㅜ

반성은 다음 TIL에서 하는 걸로 마무리하며, 오늘은 여기서 뿅!🤘🤘🤘🤘

ps. 앞으로 프로그래스를 통해 좋은 습관을 들이도록 노력 노력!!!

2년만에 글을 쓰며

2019년도에는 블로그를 통해 회고와 인사이트에 대한 내용을 적은 것 같아요.. 그런데 어느 순간부터 글을 쓰는 행위를 멀리하게 된 것 같아요 아마도 공부가 먼저다? 라는 생각을 했던 것 같습니다.. 돌아간다면, 일주일에 한 번 이상은 회고록을 작성할 것 같아요!

저는..

지금은 직장인이 아니에요.. 저는 아직 학생으로서 객체지향과 스프링을 학습하고 있습니다! 예전에는 무작정 구글링을 통해 코드복사?만을 한 것 같아 반성하고 있어요 지금이라도 멋진 개발자가 되기 위해 학습하고 있습니다!!

이번주에 내가 했던거

이번주는 정말 바빴던 것 같아요! 프로그래머스에서 진행하는 데브코스 백엔드 과정에 붙어서, 해당 과정에 대한 준비도 필요했고, 개인적으로 하고 있던 스터디와 프로젝트를 진행하느라~~ 잠도 제대로 못 잤어요,,

반성하고 있는거?

열심히 공부한다고 생각하는데, 항상 정말 중요한 내용에 대해 잊어버리는 것 같아서 아쉬움을 느껴요.. 그리고 가장 큰 것은 스스로를 믿고 의지하는 부분이 약한 것 같아요

나를 믿고, 내 주관을 믿어야 하는데 반성 또 반성

앞으로

저는 매주 1회 이상은 회고를 작성하려고 합니다!! 회고를 통해 이후의 나에게 좋은 인사이트를 줄거라 기대해요!!