Spring Boot

스프링 부트(Spring Boot)는 스프링(Spring)을 더 쉽게 이용하기 위한 도구이다. 스프링 이용하여 개발을 할 때, 이것저것 세팅을 해야 될 요소들이 많은데, Spring Boot는 매우 간단하게 프로젝트를 설정할 수 있게 하여 Spring 개발을 조금 더 쉽게 만들어주는 역할을 한다.

User는 스프링을 사용하기 위해서 이것저것 다양한 설정을 직접 해줘야된다는 문제점이 있다. 개발자가 실행환경이나 의존성 관리 등의 인프라 관련 등에 쓰는 에너지가 소요되는데, 프로그래밍을 하는 데 있어 매우 중요한 비즈니스를 만들기 위한 프로그래밍에 조금 더 에너지를 투입할 수 있게 Spring의 많은 부분을 자동화하였고, 많은 개발자들이 현재 Spring Boot을 이용하여 개발을 진행하고 있다.

참고 : https://melonicedlatte.com/2021/07/11/174700.html

Controller 

Spring Framework의 Controller는 사용자가 화면(View)단에서 입력이나 어떤 이벤트를 했을 경우, 그 이벤트에 맞는 화면(View)이나 비지니스 로직(Model)을 실행할 수 있도록 업데이트 해주는 역할을 한다. 즉, Model과 View를 연결해주는 다리 역할이라고 할 수 있다. 서버에서 기능별 URL이라는 API를 개설해 놓았고, 클라이언트는 필요한 정보를 얻기 위해 적절한 API에 요청한다. 즉 Controller는 이런 창구 역할을 하는 API들을 모아놓은 클래스라고 할 수 있다.

• Front-end에서 들어오는 클라이언트 측의 요청이 가장 먼저 서버 측과 맞닿는 부분
• Client의 요청을 받았을 때 그 요청에 대해 실제 업무를 수행하는 Service를 호출
• 클라이언트가 보낸 데이터가 있다면 Service를 호출할 때 전달하기 쉽게 데이터의 가공
• 모델의 업무 수행이 완료되면 그 결과를 바탕으로 화면을 구성하도록 View에 전달
• @Controller 어노테이션을 사용하여 만들어진 컨트롤러 클래스에 라우팅(Routing)할 수 있도록 요청 URL에 대해 해당하는 메소드를 매핑해줄 수 있도록 하기 위해 @RequestMapping 어노테이션을 사용한다.

참고 : https://yongku.tistory.com/2348

Service

• Service : Controller의 요청을 받아 알맞은 정보를 가공 Controller에게 재전달한다.
• Service는 위에서 언급했듯이 Repository에서 얻어온 정보를 바탕으로 자바 문법을 이용하여 가공 후 다시 Controller에게 정보를 보내는 곳이다.
• 클라이언트 즉 controller 쪽에서 바로 데이터베이스에 접근하여 정보를 얻고 가공해서 가져가는 것은 위험하다.
• 정보를 직접 CRUD하고 가공하는 과정에서 테이블에 저장된 원본의 정보가 손상될 우려가 크기 때문이다.
• 따라서 정보 변동의 위험이 큰 로직은 Service에서 진행한다.
• 추가로 이때 원본의 데이터를 사용하는 것이 아니라 데이터베이스에서 추출한 정보의 복사본인 DTO를 만들어서 로직을 조작한다.

참고 : https://velog.io/@seungho1216/Spring-BootController-Service-Repository%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

Repository

• Repository는 직역해도 '저장소'로 데이터베이스와 깊은 연관이 있음을 알 수 있다.
• 데이터단에 직접 매칭되는 Entity라는 것이 있는데, 이 Entity를 통해 데이터 테이블이 생성이 되면, 받아온 정보를 데이터베이스(ex. MySQL, mariaDB)에 저장하고 조회하는 기능을 수행한다.
• Repository : Entity에 의해 생성된 DB에 접근하는 메서드를 사용하기위한 interface이다.
• JPA를 상속받음으로써 기본적인 CRUD의 동작(함수 사용)이 가능해진다.
• JpaRepository<대상 엔티티, Entity에 접근할 객체의 Type>

< 중간 정리 >

• 컨트롤러 : @Controller (프레젠테이션 레이어, 웹 요청과 응답을 처리함)
• 로직 처리 : @Service (서비스 레이어, 내부에서 자바 로직을 처리함)
• 외부I/O 처리 : @Repository (퍼시스턴스 레이어, DB나 파일같은 외부 I/O 작업을 처리함)

DAO, DTO, VO 란? 

DAO

• DAO(Data Access Object) 는 데이터베이스의 data에 접근하기 위한 객체. DataBase에 접근 하기 위한 로직 & 비지니스 로직을 분리하기 위해 사용한다.

DTO

• DTO(Data Transfer Object) 는 계층 간 데이터 교환을 하기 위해 사용하는 객체로, DTO는 로직을 가지지 않는 순수한 데이터 객체(getter & setter 만 가진 클래스)이다.
• 유저가 입력한 데이터를 DB에 넣는 과정을 보면,
  • 유저가 자신의 브라우저에서 데이터를 입력하여 form에 있는 데이터를 DTO에 넣어서 전송한다.
  • 해당 DTO를 받은 서버가 DAO를 이용하여 데이터베이스로 데이터를 집어넣는다.

VO

• VO(Value Object) 값 오브젝트로써 값을 위해 쓰인다. read-Only 특징(사용하는 도중에 변경 불가능하며 오직 읽기만 가능)을 가진다.
• DTO와 유사하지만 DTO는 setter를 가지고 있어 값이 변할 수 있다.

참고 : https://melonicedlatte.com/2021/07/24/231500.html

Entitiy

데이터베이스는 엑셀처럼 2차원 테이블이라고 생각하면 되는데, 이 테이블에 서비스에서 필요한 정보를 다 저장하고 활용하게 된다.
엑셀의 세로의 열 부분이 Column 이고, 가로의 행 부분이 엔티티 객체가 된다. 이 테이블 전체가 엔티티 이고, 각 1개의 행들이 엔티티 객체가 되는 것이라고 생각하면 된다. 

• 실제 DB에 저장되는 내용들을 구현하는 class이다.
• 테이블에 대응하는 하나의 클래스라고 생각
• 하나의 객체가 DB의 하나의 Column처럼 작용한다.

참고 : https://velog.io/@jayjay28/%EC%97%94%ED%8B%B0%ED%8B%B0Entity

Annotation

• 사전적 의미로는 주석이라는 뜻이다.
• 자바에서 Annotation은 코드 사이에 주석처럼 쓰이며 특별한 의미, 기능을 수행하도록 하는 기술이다.
  - 프로그램에게 추가적인 정보를 제공해주는 메타데이터라고 볼 수 있다.
  - meta data : 데이터를 위한 데이터

참고(꼭 읽어보기) : https://velog.io/@ruinak_4127/Annotation%EC%9D%B4%EB%9E%80

JPA

• Java 진영에서 ORM(Object-Relational Mapping) 기술 표준으로 사용하는 인터페이스 모음
• 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스
• 인터페이스 이기 때문에 Hibernate, OpenJPA 등이 JPA를 구현함
• 참고로, JPA는 수정 메소드를 제공하지 않는다. 하지만 당연히 수정은 필요하기 때문에 JPA는 데이터 수정시, 매핑된 객체(테이블 데이터)를 조회해서 값을 변경 후 커밋하면 DB 서버에 UPDATE 문을  전송하여 UPDATE를 실행한다.
• 추가적으로 알아둬야 할 것은, 스프링에서 흔히 사용하는 것으로 알고있는 JPA는, JPA를 이용하는 spring-data-jpa 프레임워크이지 JPA는 아니다.

참고 : https://dbjh.tistory.com/77

@RequestParam, @PathVariable, @RequestBody

@RequestBody

• 요청이 온 데이터(JSON이나 XML형식)를 바로 Class나 model로 매핑하기 위한 Annotation이다.
• POST나 PUT, PATCH로 요청을 받을때에, 요청에서 넘어온 body 값들을 자바 타입으로 파싱해준다.
• HTTP POST 요청에 대해 request body에 있는 request message에서 값을 얻어와 매핑한다.
• RequestData를 바로 Model이나 클래스로 매핑한다.
• 이를테면 JSON 이나 XML같은 데이터를 적절한 messageConverter로 읽을 때 사용하거나 POJO 형태의 데이터 전체로 받는 경우에 사용한다.

@RequestParam

• @PathVariable과 비슷하다.
• request의 parameter에서 가져오는 것이다. method의 파라미터에 사용된다.
• ?moviename=thepurge 와 같은 쿼리 파라미터를 파싱해준다.
• HTTP GET 요청에 대해 매칭되는 request parameter 값이 자동으로 들어간다.
• url 뒤에 붙는 parameter 값을 가져올 때 사용한다.
• @RequestParam 어노테이션의 괄호 안의 문자열이 전달 인자 이름(실제 값을 표시)이다.

@PathVariable

• method parameter 앞에 사용하면서 해당 URL에서 {특정값}을 변수로 받아 올 수 있다.
• HTTP 요청에 대해 매핑되는 request parameter 값이 자동으로 Binding 된다.
• uri에서 각 구분자에 들어오는 값을 처리해야 할 때 사용한다.
• REST API에서 값을 호출할 때 주로 많이 사용한다.

< 간단 정리 >

@RequestParam : GET 방식으로 넘어온 URI의 queryString을 받기 적절

@PathVariable : URI 경로의 일부를 파라미터로 사용할 때 이용

@RequestBody : xml이나 json 기반의 메시지를 사용하는 요청의 경우 유용

참고 :

https://velog.io/@ruinak_4127/Annotation%EC%9D%B4%EB%9E%80

https://u0hun.tistory.com/21

패키지(Package)

• 자바에서는 클래스를 체계적으로 관리하기 위해 패키지(Package)를 사용한다.
• 패키지의 물리적인 형태는 파일 시스템의 폴더이지만, 단순히 파일 시스템의 폴더 기능만 하는 것은 아니다.
• 패키지는 클래스의 일부분으로 클래스를 유일하게 만들어 주는 식별자 역할을 한다.
• 즉, 클래스 이름이 동일하더라도 패키지가 다르면 다른 클래스로 인식한다.
• 형태는 : package 상위패키지.하위패키지.클래스

패키지 선언

• 클래스를 작성할 때 해당 클래스가 어떤 패키지에 속할 것인지를 선언하는 것을 의미한다.
• 패키지는 클래스의 일부이다. 이유는, 클래스만 따로 복사해서 다른 곳으로 이동하면 클래스를 사용할 수 없기 때문! 
• JDK 8 이전 버전에서는 패키지가 없는 클래스를 선언할 수 있었지만, JDK 11버전 이후 버전부터는 패키지가 없는 클래스를 생성하면 컴파일 에러가 뜬다.

① 패키지 이름의 규칙

• 숫자로 시작해서는 안 되고, _ $를 제외한 특수문자를 사용할 수 없다.
• java로 시작하는 패키지는 자바 표준 API에서만 사용하기 때문에 사용하서는 안된다.
• 모두 소문자로 작성하는 것이 관례이다.
• 참고로 여러 개발 회사들이 함께 참여하는 프로젝트의 경우 중복을 방지하기 위해 회사 도메인 이름으로 패키지를 만든다.

② import문

• 사용하고자 하는 클래스 또는 인터페이스가 다른 패키지에 소속되어 있따면 import문으로 해당 패키지의 클래스 또는 인터페이스를 가져와 사용할 것임을 컴파일러에게 알려줘야 한다.

• 형식은 다음과 같다.
  • import 상위패키지.하위패키지.클래스이름;
  • import 상위패키지.하위패키지.*; (사용하고자 하는 클래스들이 동일한 패키지 소속일 경우 *을 사용)

• import문은 패키지 선언과 클래스 선언 사이에 작성한다.
• import문은 개수에 제한이 없고 얼마든지 추가할 수 있다.
• 주의할 점은 상위패키지를 import했다고 해서 하위 패키지까지 impoprt되는 것은 아니라는 점
• 즉, com.hankook과 com.hankook.project는 서로 다른 패키지로 인식된다.

※ 만약 서로 다른 패키지에 동일한 클래스 이름이 존재하고, 두 패키지가 모두 import된 경우 컴파일에러가 발생한다.

• 이 경우에는 정확하게 패키지가 포함된 클래스 전체 이름을 기술해야 한다.
• 예를 들어, 두 패키지에 Tire라는 동일한 클래스명이 존재할 경우, 아래와 같이 전체 이름을 표기.
• ex) sec06.exam02.hankook.Tire Tire1 = ....,  sec06.exam02.kumho.Tire Tire2 = ....

접근 제한자

• 접근 제한자(Access Modifier)는 말 그래로 접근을 제한하기 위해 사용된다.
• 여기서 접근이란, 클래스 및 인터페이스 그리고 이들이 가지고 있는 멤버의 접근을 의미한다.
• 클래스와 인터페잇를 다른 패키지에서 사용 못하도록 막을 필요가 있을 경우 사용한다.
• 객체 생성을 막기 위해 생성자를 호출하지 못하게 하거나 필드나 메소드를 사용하지 못하도록 하는 경우도 사용한다.
• 클래스를 선언할 때 public을 생략했다면, 클래스는 defalut 접근 제한을 가진다.
• 클래스에 생성자를 선언하지 않으면 컴파일러에 의해 자동으로 기본 생성자가 추가된다. 

Getter와 Setter 메소드

• 객체의 필드를 객체 외부에서 직접적으로 접근하는 것을 막기위해 사용.
• 그 이유는 외부에서 마음대로 변경할 경우 객체의 무결성(결점이 없는 성질)이 깨질 수 있기 때문
• 예를 들면, 자동차 속력은 음수가 될 수 없는데 외부에서 음수로 변경할 경우 무결성이 깨진다고 할 수 있다.
• 클래스를 선언할 때 가능하다면 필드를 private로 선언해서 외부로부터 보호하고, 필드에 대한 Setter와 Getter 메소드를 작성해서 필드값을 안전하게 변경/사용하는 것이 좋다.

① Setter : 외부에서 값을 받아 필드를 변경하는 메소드

• 필드는 외부에서 접근할 수 없도록 막고, 외부에서 메소드를 통해 필드에 접근하도록 하는 메소드
• 메소드는 매개값을 검증해서 유효한 값만 객체의 필드로 저장할 수 있도록 한다.

② Getter : 필드의 값을 외부로 리턴해 주는 메소드

• 메소드로 필드값을 가공한 후 외부로 전달하는 역할
• 예를 들어 자동차의 속도를 마일에서 km단위로 환산해서 외부로 리턴해주는 getSpeed() 메소드를 다음과 같이 작성 할 수 있다.

1. 어려웠던 부분  : 항해99에서 제공한 강의를 바탕으로 게시판 CRUD 기능을 구현해야 한다. 강의에서 알려주는 부분은 이제 대충 알 것 같은데, 추가적으로 구현해야하는 부분이 아직도 어떻게 손을 대야할지 모르겠다.

2. 느낀 점 : 어떻게 공부해야 스프링을 더 잘 이해하고 사용할 수 있을까? 항해99 강의로는 너무 개념이해가 안되서 인프런 김영한 선생님 강의를 듣고 있었는데, 기술매니저님이 지금 그거 들을 때가 아니고 스파르타 강의 듣고 과제를 구현하면서 공부하라고 하셨다. 근데, 진짜 기본이 아예 없는 내가 스파르타 강의로만 흐름을 이해하고 주어진 과제를 완성하기가 쉽지 않다. 그래도 은솔님 덕분에 흐름을 많이 이해하긴 했는데, 내일은 오늘 작성한 코드를 다시 찬찬히 뜯어봐야 겠다.

3. 새로 알게 된 내용 : 스프링 Entity, Repository, Service, DTO, Controller 의 흐름을 대략적으로 이해 할 수 있을 것 같다.

4. 셀프칭찬 (오늘 잘한 일) : 들었던 강의를 다시 들으면서 다시 또 다시 또 다시 또 다시 공부했다. 강의자료도 꼼꼼히 읽어보려 했다. 물론 아직 100% 이해가 되지 않지만 그래도 처음보다는 좀 더 이해하고 있는 것 같다. 욕심내지 말자. 어제보다 오늘 그래도 좀 더 나아졋으니까 괜찮다.

5. 내일 할 일 : chap06-6 공부(오전 11시 반까지), 코드 다시 확인해보기, 과제 구현 못한 부분 다시 해보기.

[오늘 공부한 부분]

• 스프링 기본 개념 - [01] Spring Boot 기본 개념 알고 시작하자 !
• 인프런 김영한 선생님 스프링 입문 섹션 4까지
• 항헤99 스프링 입문 강의 1주차 복습

https://plo-developdiary.tistory.com/m/62

스프링 이해를 도왔던 참고 블로그 자료 내일 다시 보자 ! 

[이번주 회고]

1. 어려웠던 부분 : 

• 알고리즘 마라톤 28문제 + 챌린지 4문제 + 테스트 4문제
  • 처음엔 코드를 작성하는 법도 모르고 문제자체도 어려워서 당황스러웠다. 10년 전 수능 수학공부 생각도 나고, 머리를 쥐어짜며 목표했던 28문제를 꾸역 꾸역 끝냈다. 문제풀이에서 그치지 않고, 다른 사람들의 코드를 보며 어떻게 하는 것이 더 좋은 방법인지 배우려고 했다. 덕분에 메소드를 많이 알게 되었다. 아쉬운 점은 시간이 제한적이라 Arraylist, hashmap, stream 공부가 메소드 공부에 비해 부족했다는 것.
• 자바 - 클래스 
  • 객체지향이라는 것이 무엇인지 클래스를 공부하면서 이해하려고 노력했다. 코딩에서 설계도라 할 수 있는 클래스를 작성하는 과제가 주어졌는데, 하루종일 하고 제출 시간이 지나서야 끝낼 수 있었다. 사고를 구조적으로 해야한다는 말이 무엇인지 체감할 수 있었다. 너무 어려운데, 앞으로 계속 코딩을 하다보면 잘 할 수 있을까?
• 스프링 입문 강의 시작
  • 자바 공부도 다 끝내지 못한 상태로 스프링 강의를 시작해서 그런지, 입문강의로 들은 인프런 김영한 선생님의 강의도, 그리고 항해에서 제공한 강의 둘다 너무나 어려웠다. 스프링과 나 사이에 큰 벽이 있는 느낌이랄까. 이번주는 너무 지쳐서 내일 다시 차근차근 해보려 하는데, 다음주는 제발 좀 더 스프링과 친해 질 수 있기를.

2. 느낀 점 : 산넘어 산 이다. 첫 술에 배부를 수 없다는 말이 있지만, 이번주는 뭔가 더 큰 벽을 느낀 한 주 였다. 지난주까지 열심히 쓰던 파이썬을 내려놓고, 자바를 사용해서 알고리즘을 풀었던 과정이 너무나 힘들었는데 알고리즘 끝내자마자 숨돌릴 틈도 없이 바로 스프링으로 또 한방 맞은 느낌이랄까. 너무 어렵고 또 이해하지 못하는 내 자신이 답답한 한 주 였다. 나중에 이 글을 보며 그땐 그랬지 하는 날이 오기를. 지금의 나를 의심하지 말고 일단 2월까지 나를 믿고 잘 마무리 하자.

3. 새로 알게 된 내용 : 다양한 클래스 메소드들, 객체지향이란 무엇인지, 스프링의 대략적인 흐름, 알고리즘 푸는 법. 참 많이 배웠구나 이번주도. 화잇탱.

4. 셀프칭찬  : 하루에도 몇번씩 이 공부를 해도 되는 건지, 내가 잘 마무리할 수 있을지 고민했던 정신적으로 힘든 일주일이었다. 멘탈이 흔들릴때마다 항해99 출신인 기술매니저님들에게 용기를 구했고, 멘탈을 부여잡았다. 다른 사람들과 대화할 시간조차 없을 정도로 많이 바빴던 한주 잘 버텼다! 다음주도 쉽지 않겠지만, 끝까지 스스로를 의심하지 말고 하는데까지 스스로를 칭찬해 주자 : ) 

5. 내일 할 일 : 스프링 인프런 강의 섹션4부터 마저 듣기, 스파르타 스프링 강의자료 보면서 블로그 정리하기, TIL작성, 자바 chap6 끝내기

[ 이번주 공부한 부분 ]

• 알고리즘
• 자바 클래스 (언어 스터디)
• 스프링 입문강의 시작

[ 공부했던 부분 링크 ]

[09] Java 클래스 - 객체 지향 프로그래밍

[10] JAVA - 필드(Field)

[11] JAVA String, StringBuilder 클래스

[12] JAVA 예외처리

[13] JAVA String 클래스 메소드 정리

[14] JAVA Math 클래스 메소드

[15] JAVA 생성자 (Constructor)

[16] JAVA 메소드

[17] JAVA 자료구조 ArrayList

[18] JAVA 인스턴스(객체) Instance

https://gyoogle.dev/blog/web-knowledge/spring-knowledge/%5BSpring%20Boot%5D%20Test%20Code.html

기술매니저님이 추천해주신 사이트 - 면접 준비 시 살펴보자 ! 

• 객체의 필드값이 모두 같아야 한다면 모든 객체의 필드값을 같게 맞추는 것 보다 필드를 한 곳에 위치시키고 객체들이 그 필드를 공유하는 것이 메모리 낭비를 줄일 수 있다. 
• 자바는 이런 경우를 위해 클래스 멤버를 인스턴스 멤버와 정적 멤버로 구분해서 선언할  수 있도록 한다.
  • 인스턴스 멤버 : 객체마다 가지고 있는 멤버
  • 정적 멤버 : 클래스에 위치시키고 객체들이 공유하는 멤버

인스턴스 멤버와 this

① 인스턴스 멤버

• 객체를 생성한 수 사용할 수 있는 필드와 메소드. 각각 인스턴스 필드, 인스턴스 메소드라고 한다.
• 인스턴스 멤버는 객체 소속된 멤버이기 때문에 객체없이 사용할 수 없다.

② 인스턴스 멤버 선언

• 인스턴스 필드는 객체마다 따로 존재하고 힙 역역에 저장된다. 
• 인스턴스 메소드는 메소드 영역에 저장되고 공유된다.
• 메소드는 코드 블록이므로 객체마다 동일한 코드 블록을 가지고 있을 필요가 없기 때문!

③ this

• 객체 내부에서 인스턴스 멤버에 접근하기 위해 this를 사용할 수 있다.
• this는 주로 생성자와 메소드의 매개 변수 이름이 필드와 동일한 경우, 인스턴스 멤버인 필드임을 명시하고자 사용된다.

정적 멤버와 static

① 정적 멤버 선언

• 정적 멤버 : 클래스에 고정된 멤버로 객체를 생성하지 않고 사용할 수 있는 필드와 메소드를 말한다.
• 정적 필드와 정적 메소드를 선언하려면 메소드 선언 시 static 키워드를 추가적으로 붙이면 된다.
• 정적 필드와 정적 메소드는 클래스에 고정된 멤버이므로 클래스 로더가 클래스를 로딩해서 메소드 메모리 영역에 적재할 때 클래스별로 관린된다. 
• 따라서 클래스의 로딩이 끝나면 바로 사용할 수 있다.
• 객체마다 가지고 있어야 할 데이터라면 인스턴스 필드로 선언하고, 객체마다 가지고 잇을 필요가 없는 공용 데이터라면 정적 필드로 선언한다. ex - Calculator 클래스에서 변하지 않는 값인 원주율 파이는 정적 필드로, 값이 변하는 color는 인스턴스 필드로 선언.
• 메소드 역시 인스턴스 필드를 포함하고 있다면 인스턴스 메소드로 선언하고, 인스턴스 필드를 포함하고 있지 않다면 정적 메소드로 선언한다.

② 정적 멤버 사용

• 클래스가 메모리로 로딩되면 정적 멤버를 바로 사용할 수 있는대, 클래스 이름과 함께 도트(.) 연산자로 접근한다.
  • 클래스.필드;
  • 클래스.메소드(매개값...);

③ 정적 메소드 선언 시 주의할 점

• 객체가 없어도 실행된다는 특징 때문에 정적 메소드를 선언할 때는 이들 내부에 인스턴스 필드나 인스턴스 메소드를 사용할 수 없다.
• 또한 자신의 참조인 this 키워드도 사용이 불가능하다.
• 정적 메소드에서 인스턴스 멤버를 사용하고 싶다면, 객체를 먼저 생성하고 참조 변수로 접근해야 한다.

싱글톤(Singleton)

• 전체 프로그램에서 단 하나의 객체만 만들도록 보장해야 하는 경우 단 하나만 생성된다고 해서 이 객체를 싱글톤이라고 한다.
• 생성자를 외부에서 호출할 수 없도록 생성자 앞에 private 접근 제한자를 붙여 준다.
• 그리고 자신의 타입인 정적 필드를 하나 선언하고 자신의 객체를 생서해 초기화한다.
• 정적 필드도 private 접근 제한자를 붙여 외부에서 필드값을 변경하지 못하도록 막는다.
• 대신 외부에서 호출할 수 있는 정적 메소드인 getInstance() 를 선언하고 정적 필드에서 참조하고 있는 자신의 객체를 리턴한다.

final 필드와 상수

① final 필드

• 저장된 초기값이 최종값이므로 수정할 수 없다.
• 초기값을 주는 방법은 필드 선언 시에 주는 방법과 생성자에서 주는 방법이 있다.
• 만약 초기화되지 않은 final 필드를 그대로 남겨두면 컴파일 에러가 발생한다.
• final 필드는 final 키워드로 선언한다.

② 상수 (constant)

• 불변의 값을 상수라고 한다. 불변의 값은 수학에서 사용되는 원주율 파이나 지구의 무게 및 둘레 등이 해당된다.
• final 필드는 객체마다 저장되고 생성자의 매개값을 통해서 여러 가지 값을 가질 수 있지만 상수는 불변의 값이고 공용성을 띠고 있다는 점에서 차이가 있다. 
• 상수는 한번 초기값이 저장되면 변경할 수 없다.
• 상수 이름은 대문자로 작성하는 것이 관례이다. 혼합된 이름이라면 (_)언더바로 단어들을 연결해준다.
• 상수는 static final 키워드로 선언한다.