[8주차] 최원빈 학습 PR 제출합니다.

week02/한승규.md

@@ -0,0 +1,160 @@
+# Week2
+
+작업자: 승규 한
+상태: 진행 중
+요약: Week1
+마감일: 2024년 3월 31일
+
+# Practice-oop-banking
+
+## 구조
+
+흐름
+
+RunBanking → Person → BankingKiosk → BankServiceMediator → Clerk(CreateAccountClerk, DepositClerk, WithdrawClerk, RemittanceClerk, ChangeStatusClerk, GetAccountInfoClerk) → BankSystem ↔BankStorage
+
+Test
+
+패키지
+Account(계좌관련), Bank(은행관련), exception(예외), interest(이자관련), person(사람), validate(공통 검증)
+
+- RunBanking
+
+    프로그램 실행 클래스
+
+- Person
+
+    뱅킹 서비스 이용자로 은행 업무를 볼지 안 볼지 의사결정을 한다.
+
+- BankingKiosk
+
+    은행서비스 중 어떤 서비스를 이용할지 결정한다.
+
+- BankServiceMediator
+
+    선택한 은행 서비스에 따라 적절한 은행원을 매칭 시켜준다
+
+- Clerk(CreateAccountClerk, DepositClerk, WithdrawClerk, RemittanceClerk, ChangeStatusClerk, GetAccountInfoClerk)
+
+    은행원 클래스로 각각의 은행원 역할에 따라 서로 다른 입력을 받고 수행하며 수행 결과를 알려준다.
+
+
+- BankSystem
+
+    은행 시스템으로 계좌번호 랜덤 생성,  BankStorage에서 계좌 정보들을 가져오고 그에 따른 역할을 수행 등 여러 기능을 하는 은행 시스템이다.
+
+
+- BankStorage
+
+    은행의 계좌 저장소로 등록된 모든 계좌들을 가지고 있는 저장소다.
+
+- Account(DepositAccount, SavingAccount)
+
+    계좌 도메인으로 입금, 출금, 송금, 상태 변경 계좌 정보 확인 로직이 있으며 계좌별 이자 정책을 가져 입금 시 이자를 계산해 준다. 
+
+
+---
+
+## 과제 요구사항 변경점
+
+1. 계좌 클래스의 속성 계좌 종류를 “N”, ” S”대신 “예금 계좌”, “적금 계좌로” 저장하였다 
+2. 적금계좌를 예금 계좌에서 상속 받지않고 예금계좌, 적금계좌 모두 Account Interface를 상속받게 하였다.
+3. 계좌 클래스에 상태 변경 메서드 추가
+4. 각 계좌 클래스마다 이자율을 알고 있다.
+5. 중앙은행 클래스에서 다른 기능을 구현하지는 않았고 ArrayList가 아닌 Map으로 BankStorage에 모든 계좌가 저장될 때마다 중앙은행에도 같이 저장시켰다. (Test 클래스의  showCentralBankAccountList()메서드에서 확인)
+
+---
+
+## 구현 기능
+
+Person이 은행 업무를 처리할지 결정 후
+
+- 계좌 생성
+- 입금
+- 출금
+- 송금
+- 계좌 상태 변경
+- 계좌 정보 조회
+
+---
+
+## 예외 처리
+
+person의 행동 범위 내의 숫자 제외 예외
+
+kiosk 값 입력 범위 내의 숫자 제외 예외
+
+계좌 생성 : CreateAccountClerk에서 계좌 유형 입력 예외 처리
+
+입금 : DepositClerk에서 계좌번호 형식, 금액 입력 형식 예외 처리
+
+     BankSystem에서 계좌 못 찾은 경우, 비활성화 계좌인 경우
+
+출금 : WithdrawClerk에서 계좌번호 형식, 금액 입력 형식 예외 처리
+
+          BankSystem에서 계좌 못 찾은 경우, 비활성화 계좌인 경우
+
+    Account 클래스에서 예금의 경우 잔고 없으면 출금 불가 적금의 경우 잔고, 목표금액 부족하면 출금 불가
+
+송금 : RemittanceClerk에서 계좌번호 형식, 금액 입력 형식  예외 처리
+
+          BankSystem에서 계좌 못 찾은 경우, 비활성화 계좌인 경우 
+
+    Account 클래스에서 출금 계좌 잔고 또는 목표금액 부족 시 출금 불가 
+
+계좌상태 변경 : ChangeStatusClerk에서 계좌번호 형식 예외 처리
+
+                    BankSystem에서 계좌 못 찾은 경우
+
+계좌 정보 확인 : GetAccountInfoClerk에서 계좌번호 형식 
+
+                          BankSystem에서 계좌 못 찾은 경우
+
+---
+
+과제 작성 중 고민 내용
+
+객체지향 코드를 작성하며 고민한 점들을 작성한다.
+
+1. 구조
+
+    객체지향 Banking 코드를 작성하면서 처음부터 끝까지 구조를 많이 변경했다. 처음 설계 과정에서는 과제 요구사항에 나와있는 Class를 기반으로 MVC 구조를 통해 작성하면 될것 같다고 생각했다. 하지만 막상 내가 설계한 대로 MVC 구조를 작성하면서 내 방식의 설계가 과제의 요구사항과는 맞지 않는 것 같다는 생각이 들었다. (지금 드는 생각은 설계가 미흡했던 것 같다.)
+
+    그 이유는 서비스 클래스에서 담당하는 역할이 너무 많다고 느꼈고 은행, 계좌, 이자 간의 관계가 처음에 설계한 대로 짜이지 않고 의존관계가 엉켰기 때문이다. 이때 너무 MVC 구조에 얽매이지 말라는 조언을 듣고 익숙하지 않더라도 각각의 도메인을 세분화시켜 MVC 구조에 국한되지 않으며 도메인 중심 설계를 해봐야겠다는 생각이 들었다.  
+
+    코드를 작성하는게 오랜만이기도 하고 설계 단계에서 각 도메인의 책임을 어떻게 분리할지 고민하는 데에 시간을 많이 쓰면서 이 기능은 어느 도메인에 포함되는게 적절할까? 같은 고민을 많이 했던 것 같다.  ex) 처음에는 계좌번호를 한글로 작성하면 은행 시스템에서 예외를 처리하게 했는데 생각해 보니 은행 시스템보다는 은행원 차원에서 예외 메시지를 작성해 줘야 하는 게 적절하겠다는 생각을 함
+
+    결과적으로 사람, 은행(키오스크, 은행원, 은행 저장소), 계좌, 이자 도메인을 중심으로 코드를 작성하게 되었다. 
+
+2. 예외처리
+
+    계좌에서 예외를 던지면 은행원(clerk) 차원에서 에러 메시지를 보여주게 작성하였다.
+
+    예외 처리를 하면서 고민이 있었는데 그냥 모두 하나의 예외로 처리할지 각각의 예외 상황마다 다른 예외로 처리할지 고민했다. 이 부분에 대한 결론은 exception 패키지에 각각의 예외 상황마다 클래스를 따로 만들어 주어 처리했다. 이 방법이 맞는 건지는 잘 모르겠다.
+
+3. 계좌의 출금가능여부 검증로직
+
+    출금 가능 여부 검증 로직을 계좌 클래스에 둘 것인가 검증 클래스에 둘 것인가 고민을 했다. 계좌 클래스에 두면 계좌상태에 대한 책임이 객체 안에서 캡슐화되어 srp가 지켜진다 생각했고 접근성이 좋다는 장점이 있지만 재사용성이 떨어진다 생각했다.
+
+    검증 클래스에 두면 재사용성이 증가하고 검증을 계좌가 담당하지 않으니 이 또한 srp가 증가하는게  아닌가? 라는 생각을 했다 하지만 한편으론 검증 클래스에 의존성이 생기니까 안 좋은 방법인 것 같다는 생각도 했다. 
+
+    결론적으로 나는 내가 설계한 계좌 도메인은 계좌에 관련된 기본적인 행위?를 제어하는게 주요 책임으로 생각했기 때문에 계좌에 검증 로직을 넣는게 맞다고 생각해 넣었다.
+
+4. 계좌의 메서드 리턴 값
+
+    계좌 클래스의 메서드들을 boolean 으로하고 시스템에서 메시지를 은행원에게 넘겨주는게 String을 반환하는 것보다 좋지 않을까 생각했는데 3항연산자를 사용할 경우는 예외를 던지지도 못하고 그러므로 시스템 클래스에 if else 문이 많아져 가독성이 떨어질 것 같아 String을 반환하는게 낫겠다고 생각했다(.(이런 경우에는 어떤 것에 더 중점을 두어 구현해야 하는건지 잘 모르겠다.)
+
+
+1. 코드 작성
+
+    코드를 작성하면서 내가 적절한 상황에 적절한 것을 작성하고 있는 건지 의문이 들었다. 이러한 의문은 주로 if나 switch, Map을 사용하면서 들었던 것 같다. 최대한 코드를 간결하고 명확하게 작성하고 싶었고 그런 방향으로 작성하려고 노력했지만 분명 그렇지 않은 부분이 존재할 것이라고 생각한다. 
+
+    의존관계나 각각의 클래스가 단일 책임 원칙을 잘 준수하고 있는가에 대한 의문도 존재했다.
+
+    ---
+
+    ## 느낀 점
+
+    구조를 엎고 설계하는 과정이 반복되면서 시간적 여유는 점점 줄어들었다.
+
+    이번 과제를 통해 오랜만에 코드를 직접 작성하는 시간을 가졌는데 이 코드를 작성하면서 내가 몰랐거나 까먹었던 것을 찾아보고 공부하면서 알게 되었던 것이 많아서 좋았다.

week07/한승규.md

@@ -0,0 +1,115 @@
+# Week7
+
+작업자: 승규 한
+상태: 시작 전
+요약: Week1
+마감일: 2024년 5월 5일
+
+## 스프링 장점/사용이유
+
+스프링을 사용하면 스프링에서 제공하는 여러 핵심 요소들을 사용하여 개발 과정에서 비즈니스 로직에 집중하여 개발할 수 있게 도와준다.
+
+### 핵심요소
+
+1. 의존성 주입
+
+    의존성 주입은 컴포넌트 간의 의존성을 외부에서 제어하고 관리해 주는 것으로 이러한 의존성 주입을 통해 코드 간의 결합도를 낮추어 유지 보수성, 테스트 용이성을 높일 수 있다.
+
+
+
+2. 데이터 액세스 지원
+
+    JDBC, JPA 같은 데이터 액세스 기술을 추상화여 제공해 준다. 이를 통해 데이터베이스 작업을 간단하고 쉽게 할수있다.
+
+3. AOP
+
+    AOP는 비즈니스 로직으로부터 부가적인 기능 (공통관심사)를 분리함으로 코드의 재사용을 증가시키고 유지 보수를 용이하게 해준다. 
+    대표적으로 트랜잭션 관리, 로깅, 보안 등이 있다.
+
+
+이외에도 트랜잭션관리, 모듈러 아키텍쳐와 같은 여러 장점들이 존재하고 이러한 장점들이 개발과정을 효율적으로 만들어주기 때문에 개발자들이 핵심 비즈니스 로직에 더 많은 시간을 들일 수 있다는 장점이 존재한다.
+
+## 싱글톤, 싱글톤 컨테이너
+
+### 싱글톤
+
+싱글톤은 프로그램에서 특정 클래스의 인스턴스가 하나만 존재하는 개념이다. 이러한 싱글톤은 클래스의 인스턴스를 프로그램 전체에서 공유하여 사용해야 할 때 유용하다. 이러한 싱글톤 개념을 사용하기 위해 객체 인스턴스를 2개 이상 생성하지 못하게 막아주는 싱글톤 패턴을 디자인 패턴으로 사용하기도 한다.
+
+### 싱글톤 컨테이너
+
+싱글톤 컨테이너는 클래스의 인스턴스를 하나만 생성하고 관리해 주는 컨테이너를 말한다.
+싱글톤 컨테이너는 인스턴스의 유일성을 보장하고 해당 인스턴스를 전역적으로 접근할 수 있게 해주며 인스턴스가 생성부터 소멸까지 생명주기를 관리해 준다.
+
+스프링 컨테이너는 이러한 싱글톤 스코프의 특성을 기본적으로 사용하며 싱글톤 외에도 프로토타입, 리퀘스트, 세션 등의 스코프를 사용한다.
+
+## 레이어드 아키텍쳐 패턴
+
+레이어드 아키틱쳐는 소프트웨어를 여러 개의 계층으로 분리해서 설계하는 방법을 말한다.
+
+이러한 레이어드 아키텍쳐는 애플리케이션, 복잡도, 요구사항 등 여러 요소에 따라 그 구성이 달라지므로 각각의 계층을 외우기보다 계층의 분리를 통해 서로의 의존성을 줄여 유지 보수와 확장성을 높이기 위한 설계법이라는 것을 아는 것이 좋다.
+
+레이어드 아키텍쳐의 주요 계층에는 3가지가 존재한다.
+
+1. 표현 계층 **(Presentation Layer)**
+
+    표현 계층은 사용자 인터페이스와 입력 처리를 담당한다. → 사용자의 요청과 응답을 담당한다.
+
+2. 비즈니스 로직 계층 **(Presentation Layer)**
+
+    비즈니스 로직 계층은 애플리케이션 핵심 기능과 비즈니스 로직을 담당한다.
+
+3. 데이터 액세스 계층 **(Data Access Layer)**
+
+    데이터 액세스 계층은 데이터베이스와 같은 저장소와의 통신을 담당하는 게층이다.
+
+
+이러한 방식으로 계층을 세부적으로 분리하는 레이어드 아케텍쳐 패턴을 사용하면 각 계층의 변경이 다른 계층에 미치는 영향을 최소화하면서 요구사항에 따라 계층을 유연하게 추가, 제거할 수 있다.
+
+## 스프링 어노테이션 10개 이상 정리
+
+`@ResponseBody`
+
+http응답에 JSON, XML같은 형식의 메서드 데이터 반환값을 http 응답 본문으로 전송하게 해주는 어노테이션.
+
+`@controller`
+
+컨트롤러 레이어를 정의해주며 웹 페이지를 반환해준 어노테이션.
+
+`@RestController` 
+
+컨트롤러 레이어를 정의해준다는 점에서 `@controller` 어노테이션과 유사한 역할을 하지만 모든 메서드에`@ResponseBody` 가 자동으로 적용되어 JSON or XML같은 형식으로 데이터를 http 응답 반환해주는 어노테이션.
+
+`@RequestMapping`
+
+Http 요청이 들어왔을때 설정해놓은 경로에 따라 메서드를 매핑시켜주는 어노테이션. 
+구체적인 매핑 메서드가 존재할 때는 구체적인 어노테이션이 붙은 메서드가 실행된다.
+
+`@PostMapping`
+
+http Post 요청이 들어온 경우 설정해놓은 경로와 맞을때 매핑시켜주는 어노테이션
+
+`@GetMapping`
+
+http Get 요청이 들어온 경우 설정해놓은 경로와 맞을때 매핑시켜주는 어노테이션
+
+`@Configuration` 
+
+스프링 IoC 컨테이너에 의해 빈 정의를 제공하는 설정 클래스임을 나타내주는 어노테이션.
+
+`@Transactional` 
+
+메서드의 실행을 하나의 트랜잭션으로 처리하게 해줌으로 트렌잭션 경계를 정의해주는 어노테이션
+
+성공 시 트랜잭션을 커밋하고 실패시 롤백해준다.
+
+`@Autowired` 
+
+스프링 컨테이너에서 의존관계 주입을 자동으로 해주기 위해 사용되는 어노테이션.
+
+`@ModelAttribute`
+
+메서드의 파라미터가 http요청 파라미터에서 값을 바인딩 받거나 Model 객체에 데이터 추가를 할 때 사용되는 어노테이션.
+
+`@PathVaribale` 
+
+url의 경로변수를 메서드의 파라미터로 바인딩할 때 사용되는 어노테이션.