스터디/이펙티브자바

[아이템3] private 생성자나 열거 타입으로 싱글턴임을 보증하라

아이템 3 private 생성자나 열거타입으로 싱글턴임을 보증하라 p.23 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. 타입을 인터페이스로 정의한 다음 그 인터페이스를 구현해서 만든 싱글턴이 아니라면 mock 구현으로 대체할 수 없기 때문이다. 인터페이스 없이 구현한 싱글턴 코드 public class Validator { private static final Validator INSTANCE = new Validator(); public static final Validator getInstance() { return INSTANCE; } private int bound; private Validator() { this.bound = 10; } public vo..

2020.01.17 게시됨

스터디/이펙티브자바

[아이템2] 생성자에 매개변수가 많다면 빌더를 고려하라

[아이템2] 생성자에 매개변수가 많다면 빌더를 고려하라 점층적 생성자 패턴 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다. public class Gradation { private String name; private int number; private long money; private double temperature; public Gradation(String name, int number, long money, double temperature) { this.name = name; this.number = number; this.money = money; this.temperature = temperature; } public Gradation(String name, int ..

2020.01.16 게시됨

스터디/이펙티브자바

[아이템1] 생성자 대신 정적 팩터리 메서드를 고려하라

이펙티브 자바 2장 객체 생성과 파괴 [아이템1] 생성자 대신 정적 팩터리 메서드를 고려하라 첫번째 장점, 이름을 가질 수 있다. Example code. public class Ladder { public static Ladder left() { return new Ladder(Direction.LEFT); } public static Ladder right() { return new Ladder(Direction.RIGHT); } public static Ladder down() { return new Ladder(Direction.DOWN); } private Direction direction; public Ladder(Direction direction) { this.direction = dir..

2020.01.15 게시됨

스터디/클린코드

객체지향 설계 5원칙 SOLID

객체지향설계 5원칙 SOLID의 이해와 예제 목표 SOLID에 대한 설명을 하는 글은 여러 블로그에 소개가 되어있습니다. 하지만 대부분의 글이 개념적인 설명을 위주로 하고 있을뿐더러, 너무 추상적이라 이해하기 어렵다는 생각을 했습니다. 그래서 저는 이 글을 실제로 코드상에서 어떠한 방식으로 적용되는지 어떻게 의식하고 코드를 작성하는 것이 SOLID를 지킬 수 있는지 이 두 가지에 중점을 두고, 개념적인 설명만 있는게 아닌 예제를 통해 SOLID를 공부하고 이해해 보고자 합니다. 글에서 사용된 예제는 모두 GitHub에 올라가 있습니다. 1. SRP Single Responsibility Principle - 단일 책임의 원칙 한 클래스는 하나의 책임을 가져야 한다. SRP가 지켜지지 않은 코드 publi..

2019.12.18 게시됨

스터디/클린코드

객체지향의 사실과 오해를 읽고

들어가며 학교의 커리큘럼은 C를 배우고 Java를 배우는 순서였습니다. C는 절차지향 언어이고, Java는 객체지향 언어이다. 전혀 이해가 되질 않았습니다. 전혀. 솔직히 지금도 객체 지향에 대해 설명하라고 하면 자신있게 못 할 것 같습니다. Java는 코드의 재사용이 가능하다고 하지만 'C도 메서드 재사용 되지않나?'라는 생각을 했습니다. Java는 그저 알고리즘을 풀기위한 언어 중 한 가지일 뿐이었습니다. 그러다 우연히 대외활동을 하다 다른 친구가 Java를 다루는 것을 보았는데 충격적이었습니다. '와! 내가 작성한 코드는 쓰레기구나!' 제가 작성한 코드는 재활용이 불가능한 코드지만, 친구가 작성한 코드는 재활용도 가능하고 정말 깔끔했습니다. 저는 객체 지향언어를 사용하면서 원칙을 지키지 않았고 친구..

2019.12.04 게시됨

스터디/JPA

오늘의 에러 [ detached entity passed to persist]

발생한 에러 (2019.11.13) org.hibernate.PersistentObjectException: detached entity passed to persist 문제 발생시 도메인 상황 @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Champion { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String riotId; private String key; @Column(unique = true) private String name; @OneToMany(mappedBy = "champion", fetc..

2019.11.14 게시됨

스터디/알고리즘

[Programmers] 순위

본 게시글은 PC 환경에서 보기 편하도록 설정이 되어 있습니다. 순위 그래프 로 분류되어있는 완전탐색류 문제입니다. 저는 모든 경기수를 확인하기 위해 DFS를 이용하여 문제를 풀었습니다. 풀이 스타일 Java와 같은 객체지향 언어를 이용하여 알고리즘을 푼다면 객체지향스럽게 알고리즘을 풀어야 한다고 생각합니다. 단순한 알고리즘 풀이는 가독성은 당연히 떨어지고, Java를 쓰는 이유가 퇴색되는 것 같습니다. 따라서, Java를 이용해서 문제를 푸신다면 객체가 해야할 행동으로 문제를 풀 수 있도록 하시는 것을 추천드립니다. 모든 선수를 Boxer로, Boxer를 List로 전부 들고있는 일급컬렉션인 MatchHistory를 생성수 Boxer가 이길수 있는 모든 Boxer와 Boxer가 질수 밖에 없는 모든 B..

2019.10.20 게시됨

스터디/알고리즘

[백준] 블랙잭

본 게시글은 PC 환경에서 보기 편하도록 설정이 되어 있습니다. 블랙잭 브루트포스 로 분류되어있는 완전탐색류 문제입니다. DFS를 아신다면 가장 기본적인 수준의 난이도에 해당하는 문제일 것 같습니다. 풀이순서는 아래 과정을 반복하면 간단하게 풀 수 있습니다. 카드를 1장씩 모아 저장합니다. 카드가 3장이 되면 합을 구합니다. 2.1. 카드의 합이 목표 값보다 크다면 마지막 카드를 버리고 1번으로 돌아갑니다. 2-2. 카드의 합이 목표 값과 같다면 최대 값으로 저장후 게임을 종료시킵니다. 2-3. 카드의 합이 목표 값보다 작다면 현재 최대 값으로 알고있는 값과 비교하여 큰 값을 유지합니다. 마지막 카드를 버리고 1번으로 돌아갑니다. 풀이 스타일 Java와 같은 객체지향 언어를 이용하여 알고리즘을 푼다면 객..

2019.10.10 게시됨

스터디/알고리즘

[Programmers] 프린터

본 게시글은 PC 환경에서 보기 편하도록 설정이 되어 있습니다. 프린터 스택/큐 로 분류되어 있는 문제입니다. 우선순위 큐를 사용하고 우선순위 큐를 사용하기 위해 Comparable 의 compareTo 를 구현할 줄 안다면 쉬운문제입니다. 풀이 스타일 Java와 같은 객체지향 언어를 이용하여 알고리즘을 푼다면 객체지향스럽게 알고리즘을 풀어야 한다고 생각합니다. 단순한 알고리즘 풀이는 가독성은 당연히 떨어지고, Java를 쓰는 이유가 퇴색되는 것 같습니다. 따라서, Java를 이용해서 문제를 푸신다면 객체가 해야할 행동으로 문제를 풀 수 있도록 하시는 것을 추천드립니다. Printer 객체는 두 개의 큐를 가지고 있습니다. 우선 순위가 가장 높은 document 를 head에 가지고 있는 Priority..

2019.10.02 게시됨

스터디/데이터베이스

[이론] 트랜잭션 격리 수준 ( Transaction Isolation Level )

트랜잭션 격리 수준 (Isolation Level) 트랜잭션은 ACID 속성을 보장해야합니다. 그 중 I 에 해당하는 Isolation은 트랜잭션의 고립성을 의미하고, 고립성은 서로 다른 트랜잭션은 서로 영향을 미치지 말아야 함을 의미합니다. 하지만 이 고립성은 동시성과 충돌할 수 밖에 없는 속성입니다. 고립성 수준, 다시말해 격리 수준이 올라감에 따라 동시성이 떨어지는 문제가 발생하게 됩니다. 그렇다고 고립성 수준을 낮추게 된다면 ACID의 C, Consistency인 일관성, 즉 데이터의 무결성 문제가 발생할 수 있습니다. 따라서 서비스를 운영할 때 서비스의 성격에 알맞는 격리 수준을 선택해야 할 필요가 있습니다. 서비스와 1:1로 대응해가며 설명을 하면 좋겠지만,,, 그 정도의 경험이 있지도 않거니..

2019.10.02 게시됨