2021 02 25

문자 인코딩¶

문자표 - 숫자로 저장한 정보를 사용자에게 보여줘야 할 필요성 - 숫자 별로 표현해 줄 캐릭터를 지정해 줌 - 이 대응표가 기계별로 천차만별... "규약"이 필요해짐 - 처음 생긴게 ASCII 코드 - 근데 ASCII는 영어만 변환해 놓음 - 한국어, 일본어 등 다양한 문자열 변환에 대한 수요 발생 - 전 세계가 알아먹을 수 있는 "규약"이 필요해짐 - 그렇게 생긴게 Unicode

문자표 Encoding - 그런데 Unicode도 문제가 있었으니... - 어떤 문자는 1byte, 2byte, 3byte - 그에 따라 "몇 바이트를 읽어서 표현해줘"를 약속하게 됨 - 이게 UTF-8, UTF-16, EUC-KR 등등

값을 보관만 하고 있는 클래스라면, 그의 역할에 대해 고민해봐라 - 클래스로써 가치가 없거나 - 해당 클래스가 가져야 할 로직을 다른 클래스가 가지고 있진 않은가?

util 패키지는 도메인 기능이 아닌 범용적인 API의 기능이 들어간다 - 고로 최대한 util 패키지를 만들지 말고 구현해보자 - 그러면...음 LottoGenerator에서 랜덤 넘버 추출만 맡겨볼까?

getter는 비즈니스 로직이 아니라서 view에서 호출해도 ㄱㅊ > 물론 도메인을 보호하기 위해 DTO를 분리하는 것도 좋지만 꼭 분리하실 필요는 없을 것 같아요 ㅎㅎ

Stream vs for-Loop? > 1. for가 더 좋은 상황에선 for를 사용하고 스트림이 더 좋은 상황에선 스트림을 쓰자 > 2. 하지만 대부분의 경우는 별 차이가 없고 그러한 경우 개발 스타일을 따라가면 된다 > 3. 요즘은 스트림을 사용하는 스타일이 더 인기를 얻고 있다

시작하기 전에... - 요구사항 분석을 통한 기능 목록을 작성할 것 > [기능 목록]
구매할 Lotto의 매수 구하기
1000 -> 1
1500 -> 1
500 -> error
한장의 Lotto 생성
당첨 번호 생성
정상적인 당첨번호 입력
유효하지 않은 당첨번호
한장의 Lotto에 대한 당첨 결과 구하기
n장의 Lotto에 대한 당첨 결과 구하기
Lotto 결과에 따른 수익률 구하기
...
- 객체 설계를 통해 어느 부분부터 구현할 지 결정

리팩토링 할 때 연습 - 기존 코드에 컴파일 에러가 발생하지 않도록 리팩토링을 연습하자 - 리팩토링 과정에서 테스트 코드가 깨지지 않도록 리팩토링 연습하자

상속(is-a)보다는 조합(has-a)을 사용하자! - 참고: https://happy-playboy.tistory.com/entry/Item-18-%EC%83%81%EC%86%8D%EB%B3%B4%EB%8B%A4%EB%8A%94-%EC%BB%B4%ED%8F%AC%EC%A7%80%EC%85%98%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%98%EB%9D%BC - 상속 문제점 - 메서드 오버라이딩: 상속 받은 클래스의 동작을 완벽히 모른다면, 의도와 다르게 동작할 수도 있다 - 새로운 메서드 추가: 새로운 릴리즈에 상속받은 클래스가 리턴 타입이 다른 같은 메서드 명을 쓰는 메서드가 추가된다면? - 그 대신 조합 - 새로운 클래스를 만들고, private 필드로 기존 클래스의 인스턴스를 참조 - 기존 클래스의 메서드를 쓰도록 하자! - 이런 방식을 전달(forward) 이라고 한다 - 만약 컴포지션 대신 상속을 사용하기로 결정한다면, 다음과 같은 질문을 해봐야 한다. 1. 확장하려는 클래스의 API에 아무런 결함이 없는가? 2. 결함이 있다면, 이 결함이 여러분 클래스의 API까지 전파돼도 괜찮은가? - 컴포지션으로는 이런 결함을 숨기는 새로운 API를 설계할 수 있지만, 상속은 상위 클래스의 결함을 그대로 상속 받는다.

불변 객체를 만들기! - 객체의 상태를 변경시키는 메서드 근절 - 클래스 확장 못하게 막음 (public final class) - 모든 필드를 final로 선언 - 모든 필드를 private으로 선언

의존 객체 주입을 고려하라 - 참고: https://velog.io/@wlsdud2194/what-is-di - 의존성을 가진 코드 (한 클래스 내부에서 다른 클래스를 생성) 라면, 코드의 재활용성 떨어짐. 함께 수정해야함 - 장점 - Unit Test가 용이해진다 - 코드의 재활용성을 높여준다 - 객체 간의 의존성을 줄이거나, 없앨 수 있다 - 객체 간의 결합도가 낮아지면서 유연한 코드 작성이 가능하다 - 필요한(의존하는) 클래스를 생성하지 말고! 외부에서 주입해주자!