개발자의 공부 이야기 개발자의 공부 이야기

https://github.com/rlawls1991/effective_java/tree/main/effective/src/main/kotlin/com/effective/chapter/_4 코틀린은 쉽게 사용이 가능하다... 코틀린짱.. object 쓰면 알아서 싱글톤형태로 되기 때문에 편하다 설명 정적 메서드만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 클래스 가 아니다. 추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다. private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다. 생성자에 주석으로 인스턴스화 불가한 이유를 설명하는 것이 좋다. 상속을 방지할 때도 같은 방법을 사용할 수 있다.

https://github.com/rlawls1991/effective_java/tree/main/effective/src/main/kotlin/com/effective/chapter/_3 private 생성자 + public static final 필드 장점 간결하고 싱글턴임을 API에 들어낼 수 있다. 단점 싱글톤을 사용하는 클라이언트 테스트하기 어려워진다. 리플렉션으로 private 생성자를 호출할 수 있다. 단점 3, 역직렬화 할 때 새로운 인스턴스가 생길 수 있다. private 생성자 + 정적 팩터리 메서드 장점 API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다. 정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있다. 정적 팩터리의 메서드 참조를 공급자(Supplier)로 사용할 수 있다...

빌더 패턴이란? 설명 동일한 프로세스를 거쳐 다양한 구성의 인스턴스를 만드는 방법이다. 해당 패턴을 사용하면 복잡한 객체를 만드는 프로세서를 독립적으로 분리가 가능하다. 근데.. 코틀린에서는 빌더 패턴 사용하지 않고 클래스의 생성자에 바로 매개변수를 넣어 클래스를 정의 가능.. (추가적으로 빌더 패턴을 권장하지 않음) 아래의 페이지에 코틀린으로 빌더 패턴 고려한 것과 자바코드 버전을 비교 할 수 있다. 코틀린짱 https://github.com/rlawls1991/effective_java/tree/main/effective/src/main/kotlin/com/effective/chapter/_2/hierarchicalbuilder

장단점 장점 이름을 가질 수 있다. 동일 한 시그니처의 생성자를 두개 가질 수 없다. 호출될 때마다 인스턴트를 새로 생성하지 않아도 된다. Boolean.valueOf 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다. 인터페이스 기반 프레임워크, 인터페이스에 정적 메소드 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다 EnumSet 정적 팩터리 메소드를 작성하는 시점에는 반환할 객체의 클래스가 조회하지 않아도 된다. 사용자 제공자 프레임워크 단점 상속을 하려면 pulbic이나 proteted 생성하기 필요하니 정적 팩터리 메소드만 제공하면 하위 클래스를 만들 수 없다. 정적 팩터리 메소드는 프로그래머가 찾기 어렵다. 열거 타입 상수 목록을 담을 수 있는 데이터 타입 특정한 변수..

퇴직 후 3개월치의 월급과 퇴직금을 받으니 목표가 사라졌었다. 이를 타개하고자 회사를 다니면서 하지 못했던 일들을 진행하였다. 1. 운전면허를 취득 2. 나홀로 여행 3. 디아블로4 하기 4. 지인들과 만나 이야기 하기 5. 개인용 노트북 구매 6. 배달음식 플랙스 마지막으로 글 올린 후 위의 6가지일들을 실행하였다. 운전면허 이제 부모님이 운전하는 차를 타는 것보다 내가 운전하는 것을 미룰 수 없어 제일먼저 실행하였다. 결론만 말하면 2주동안 노력하여 운전면허를 획득하였다. 2종보통인데 학원비+시험비+보험비 = 93만원, 소렌토 운전연수 6시간 36만 6천원 .. 총합 약 130만.. 나홀로 여행 + 지인들 만나기 KTX를 타면서 부산-여수를 돌아 다녔다. 군대 선임도 만나고, 좋아하는 낚시도 하였으며..

해당 챕터의 내용을 보면서 느낀점이 첫 위메프에 입사했을때가 생각이 났다. 첫 회사에서는 서버를 DB 1개 API 1개 만 두고 사용했으나, 위메프에서는 API서버를 쿠폰(36개), 리뷰(9개)를 사용하였다. 쿠폰, 리뷰의 master DB는 3개씩 존재했으며, slave는 6개 이상이 존재하였다. 서버들을 보면서 느낀점이 위메프는 수평적 확장을 주로 진행을 했구나 라는 것이었다. 그리고 각각의 서버의 CPU사용률 및 RAM 사용률이 높은 경우 수직적인 확장을 진행하였다. 이처럼 사용자가 많으면 2가지를 섞어 쓰는 것을 배웠으며, 좀더 디테일하게 해당 내용을 공부할 예정이다. 수직적 확장(Scale up & vertical scaling) 서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM)을 추가하는..

기본적으로 회사에서 작업을 진행하면서 대규모 시스템 설계까지는 고민하지 않았다... 오늘 지인 중 한명이 이 책을 소개시켜주었다. 이 책을 읽으면서 내가 프로젝트를 진행하면서 이러한 고민을 하지 않았다는 것을 깨달았다.... 진행중인 개인 프로젝트를 멈추고 해당 책을 읽고 진행을 해아겠다.

방향을 위메프에서 작업했던 내용들 전체는 아니더라도 부분적으로 가져와서 개선시키고 싶었던 것 위주로 작업할 예정이다. 1. 물건 결제시 API를 통하여 transaction을 진행하였는데 kafka로 설정하고자 한다. 2. JPA 사용 # commerce 내맘대로 만드는 커머스 코드 ~~ ## 서버 ### 도커 실행 docker-compose -f ./docker/docker-compose-m1.yaml up ## 도메인 ### 상품 * 구매된 상품에는 리뷰를 작성할 수 있다. * 상품에는 판매 상태 컬럼이 존재한다. * 판매중, 품절 * 상품에는 상품상태 컬럼이 존재한다 * 임시 저장, 진행대기, 판매중, 판매중지 * 상품은 하나의 카테고리에만 존재할 수 있다. * 관리자는 해당 상품 노출 여부를 선택..