Lee's Grow up

[CodingConvention] Google Java Coding Style 정리

효기로그 — Tue, 8 Dec 2020 16:54:35 +0900

구글에서 제공해주는 자바 코딩 스타일 가이드에 대한 정리입니다.원문
해당 내용은 작성일 기준 문서의 내용을 정리한 것 입니다.

소스파일

이름 : 포함하고 있는 최상위 레벨의 대소문자 구분되는 이름으로 이루어집니다.
확장자 : .java 확장자를 사용합니다.
인코딩 : UTF-8
ASCII(0x20)은 유일한 공백 문자이며, 탭 문자는 공백에 사용하지 않습니다.
모든 특수 문자를 사용할 때 이스케이프 시퀀스 (\b, \w 등)을 사용하며, 그 문자의 진수, 유니코드는 사용하지 않습니다.
비 ASCII문자는 유니코드를 사용하고, 주석으로 설명해도 무방합니다.

소스파일 구조

소스 파일은 다음 순서로 구성됩니다. 각 객션 간에는 공백 라인이 하나 들어가야 합니다.
1. 라이센스 또는 저작권 정보 ( 있는 경우 )
2. 패키지 명세서
3. import문
4. 최상의 클래스

Pacakge 문

이름은 소문자로 작성합니다.
패키지문은 아무리 길어도 한 문장으로 써야합니다. 줄 바꿈 되지 않습니다.

Import 문

정적이든 비정적이든 와일드 카드(*)는 사용하지 않습니다.
순서
- 단일 블록에서 모든 정적
- 단일 블록의 모든 비 정적
정적과 비정적 사이에만 빈 줄이 있고, 다른 import 문 사이에는 다른 빈 줄이 없습니다.
각 블록 내에서의 이름은 ASCII 정렬 순서로 나타냅니다.
정적 중첩 클래스에는 정적 import가 사용되지 않습니다. 일반 import를 사용합니다.

Class

대문자로 시작하며, UpperCamelCase를 사용하며, 명사 또는 명사구입니다. 인터페이스는 명사 또는 명사구 또는 형용사 형용사구가 될 수 있습니다.
테스트 클래스의 경우 Test를 붙입니다. HashTest
클래스 멤버의 순서는 절대적인 것은 없습니다. 다만 순서가 논리적이여야 합니다. 가령 새로운 메소드가 추가되었다고 해서 클래스의 가장 마지막에 구현되는 것은 논리적이지 않습니다.
Class에 여러 생성자 또는 동일한 이름을 가진 여러 메서드가 있는 경우 사이에 다른 코드 없이 순차적으로 나타냅니다.

Method

lowCamelCase를 사용합니다.
동사구입니다.
JUnit 테스트 메서드 이름의 경우 _ 뒤엔 lowCamelCase를 따릅니다 `_ pop_emptyStack

상수

상수는 CONSTANT_CASE 구분은 밑줄로 모든 단어는 대문자로 사용합니다.

필드

lowerCamelCase를 사용합니다.
고용ㅇ 메소드에서 사용한 변수 이름은 피해야 합니다.

지역 변수

lowerCamelCase를 사용합니다.
절대로 상수로 지정해서는 안됩니다.

유형 변수 이름

임의의 단일 대문자 T, E, X 또는 클래스 이름 + T , RequestT, FooT, BarT

포메팅

들여쓰기는 2space를 사용합니다.

블록 {}

빈 블록의 경우
- 블록 문은 내용이 비어있거나, 단 하나의 문이 포함된 경우에도 사용한다.(if, else, for, do, while )
- 다중 블록이 아닌 경우, 블록({}) 사이에 문자나 줄 바꿈 없이 열린 직후 닫을 수 있습니다.
```
// 단일 블록은 둘 다 사용 가능
void doNothing() {} 
void doNothingElse() {
}
// 다중 블록은 사용 불가
try {
  doSomething();
} catch (Esception e) {} 
```
비어있지 않은 블록의 경우
- 여는 중괄호 앞에는 줄 바꿈이 없습니다.
- 여는 중괄호 뒤의 줄 바꿈
- 닫는 중괄호 앞의 줄바꿈
- 닫는 중괄호 뒤의 줄바꿈 단, 중괄호가 명령문을 종료하거나, 메서드 , 생성자 또는 클래스의 본문을 종료하는 경우에는 줄바꿈이 없습니다. 예를들어 ; ( semicolon) 또는, else 문

세로 공백

각 문 뒤에는 줄 바꿈이 있습니다. ( 한 줄에 하나의 문 )
열 제한은 100자 입니다. 단 javadoc의 긴 ULR 또는 긴 JSNI 메소드 참조나, pacakge 문, import 문은 예외입니다.
연속 줄바꿈인 경우 4space 의 indent를 사용합니다.
세로 공백은 하나의 빈줄을 사용합니다. 여러 개의 빈 줄이 허용되지만 권장은 아닙니다.
- 클래스의 필드, 생성자, 메소드, 중첩 클래스, 정적 초기화 및 인스턴스 사이에 공백이 들어갑니다.
두 개의 연속된 필드에 빈줄은 논리적은 그룹을 만드는데 사용합니다.

가로 공백

if, for, catch 다음에 오는 '(' 사이에 공백문자
else 또는 catch 이전에 오는 '}' 사이에 공백 문자
여는 중괄호 '{' 앞에 공백
- 단 어노테이션의 경우 공백 사용하지 않음 @SomeAnnotation({a, b})
- 배열의 경우 선택 사항 new int[] {5, 6} 또는 new int90 { 5, 6 }
이항 또는 삼항 연산자에서
- <T extends Foo & Bar>
- 예외 catch 블록에 대한 파이프 : catch (Exception | BarException e)
- 확장된 for문에서 ' : '
- 람다 식의 화살표 ' -> '
',:;' 또는 닫는 괄호 뒤 '}'
주석 // 의 시작 허용은 되지만 선택사항
'[]' 또는 '...' 사이

수평 정렬

수평 정렬은 사용하지 않습니다.

// 맞는 사용
private int a;
private String b;

// 틀린 사용  
private int a;  
private String b

Enum 클래스

열거 형 상수 뒤에 오는 각 쉼표 뒤에 줄 바꿈은 선택사항, 추가 빈줄도 허용합니다.

  private enum Answer {  
  YES {  
    @Override public String toString() {  
    return "yes";  
    }  
  },

  NO,
  MAYBE

배열처럼 사용 가능합니다.

  private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }

변수 선언

선언 당 변수 하나, int a, b; 는 허용되지 않습니다.
- 단 for 루프 헤더에 여러 변수 선언은 허용됩니다.
시작 부분에 습관적으로 선언하지 않고, 필요할 때 선언하며, 필요한 지점에 가깝게 선언해 범위를 최소화 합니다.

배열 선언

블록처럼 사용 가능합니다. 아래는 모두 가능합니다.

new int[] {  
0, 1, 2, 3  
}

new int[] {  
0,  
1,  
2,  
3  
}

new int[] {  
0, 1,  
2, 3  
}

new int[]  
{0, 1, 2, 3}

스타일 배열 선언을 사용하지 않습니다. String[] args 는 가능 String args[]는 사용 금지

스위치문

들여쓰기는 2spaces를 사용합니다.
default를 작성합니다.

break, continue, return이 없는 경우 // fall through 주석 사용


switch (input) {  
case 1:  
case 2:  
prepareOneOrTwo();  
// fall through  
case 3:  
handleOneTwoOrThree();  
break;  
default:  
handleLargeNumber(input);  
}

어노테이션

클래스, 메서드 또는 생성자의 주석은 문서 블록 바로 뒤에 나타나며, 각 주석은 1줄을 사용하며 들여쓰기를 사용하지 않습니다. 단 매개변수가 없는 단일 주석인 경우 한줄에 표현이 가능합니다. 필드에 적용되는 주석의 경우 한줄로 나열 될 수 있습니다.
```
@Override  
@Nullable  
public String getNameIfPresent() { ... }

## 가능
@Override public int hashCode() { ... }

## 가능
@Partial @Mock DataLoader loader;
```
매개변수, 지역변수, 타입에대한 어노테이션은 규칙은 없습니다.

Modifiers 순서

public protected private abstract default static final transient volatile synchronized native strictfp

숫자 리터럴

long의 경우 대문자 접미사를 사용합니다. 숫자 1과 혼동을 피하기 위해

네이밍

아스키 코드나 숫자만 허용하며 prefixes 또는 suffixes를 사용하지 않습니다. not use mName, KName 등

Override 어노테이션

생략하지 않습니다.단 부모 메소드가 @Deprecated인 경우 생략할 수 있습니다.

예외

catch 블록은 무조건 액션을 취합니다. 다만 테스트 케이스일 경우 생략 가능합니다.

정적 멤버

클래스 이름으로 접근합니다. 인스턴스 명으로 접근하는건 잘못 된 예시입니다.
```
Foo aFoo = ....  
Foo.aStaticMethod() // OK  
aFoo.aStaticMethod() // bad
```

Finalizers 사용 금지

Javadocs 필수가 아닙니다. 필요시 문서 참조

[Python/파이썬] 제어 - 조건문, 반복문 / if, for, while

효기로그 — Tue, 6 Oct 2020 13:35:24 +0900

해당 내용은 Pythone 공식 문서를 참조하여 작성하였습니다. 작성 기준 버전은 3.8.6입니다.

공식문서 : docs.python.org/3/tutorial/index.html

1. if 문

파이썬도 타 언어와 마찬가지로 조건을 판단하기 위해 if 문법을 제공해준다. 기본문법은 아래와 같다.

x = int(input("Enter Integer : "))

if x % 2 == 0:
    print("even")
else:
    print("odd")

내용은 입력 받은 값을 단순하게 홀수냐, 짝수이냐 판별해주는 조건문이다.
파이썬은 조건문 뒤에 :을 붙이며, 수행할 코드를 들여쓰기로 구분해줘야한다 ( 띄어쓰기 4칸 또는 tab )
해당 규칙을 지키지 않으면 SyntaxError가 발생한다.
위 내용을 조건부 표현식으로 가독성 좋게 아래와 같이 표현이 가능하다.

x = int(input("Enter Integer : "))
print("even") if x % 2 == 0 else print("odd")

다중 조건

위 예제에서는 조건이 참이냐, 거짓이냐 2가지로만 판별 가능하다. 파이썬도 타 언어와 마찬가지로 다중 조건을 줄 수 있으며, 키워드로는 elif를 사용한다. else if의 줄임말이다. 이는 파이썬이 지향하는 간결한 문법이며 과도한 들여 쓰기를 방지해 가독성을 향상 시켰다고 문서는 말한다.

menu = int(input("Select Menu 1. 아메리카노, 2. 라떼, 3. 카페모카 (번호로 선택 ): "))

if menu ==  1:
    print("아메리카노")
elif menu == 2:
    print("라떼")
elif menu == 3:
    print("카페모카")
else:
    print("없는 메뉴입니다.")

또한, elif로 대체가 가능하기 때문에 타 언어처럼 switch문이 존재하지 않는다.
번외로 조건이 너무 길어지면, 가독성이 안좋아 지기 때문에 아래처럼 딕셔너리를 활용한 사용도 가능하다. 결과는 동일하다

def switch(menu):
    return {1:"아메리카노", 2:"라떼", 3:"카페모카"}.get(menu,"없는 메뉴입니다.")

print(switch(4))

이러한 조건문에서 사용되는 비교 연산자는 ( <, >, ==, !=, <=, >= )가 있으며 조건을 판단하는 연산자로는 ( and, or, not )가 있다.

마지막으로 리스트, 튜플, 문자열, 딕셔너리인 경우 in 키워드를 통해 조건문을 쉽게 작성할 수 있다.

x = int(input("Select Menu 1. 아메리카노, 2. 라떼, 3. 카페모카 (번호로 선택 ):"))
menu = {1:"아메리카노", 2:"라떼", 3:"카페모카"};
if x in menu:
    print(menu[x])
else:
    print("없는 메뉴입니다.")

for 문

반복을 위한 구문입니다. 기본적으로 for 와 in 키워드를 사용하며 아래와 같은 기본 구조를 가집니다.

for w in words : print(w)

일련의 숫자를 반복해야 하는 경우 range() 내장함수를 같이 사용합니다.
3개의 인수를 넘겨줄 수 있으며, 각각 시작 값, 종료 값, 단계로 구분됩니다. 인수로 음수도 가능합니다.

range(5, 10) # 5, 6, 7, 8, 9
range(0, 10, 3) # 0, 3, 6, 9
range(-10, -100, -30) # -10, -40, -70

다만 range()를 통해 반환된 객체는 list처럼 동작하지만, 실제론 리스트가 아니기 때문에, 공간을 절약할 수 있습니다. 그래서 때로는 enumerate() 기능을 사용하는 것이 편리합니다.

ranage()가 반환해주는 객체를 반복 가능하다고 표현하며, 반복 가능한 함수에서 바로 사용 가능합니다.

sum(range(5))  # 0 + 1 + 2 + 3 + 4

리스트로 만들기 위해선 아래와 같이 사용합니다.

list(range(5)) # [0, 1, 2, 3, 4]

반복문은 리스트 안에 사용(List comprehension)이 가능합니다. 또한 리스트 내포에는 조건문도 사용 가능합니다.

numbers = [1, 2, 3, 4, 5]
odd = [num for num in numbers if num % 2 != 0]

break, continue, else

파이썬은 반복문에서도 else 키워드가 사용 가능합니다. else 구문의 실행문장은 break문에 의해서 루프가 종료되는 경우에는 실행하지 않습니다. 아래와 같이 사용 가능합니다. ( 소수 판별 )

for n in range(2, 10):
    for x in range(2, n):
        if n % x == 0:
            print(n, 'equals', x, '*', n // x)
            break
    else:
        print(n, 'is a prime number')
# 2 is a prime number
# 3 is a prime number
# 4 equals 2 * 2
# 5 is a prime number
# 6 equals 2 * 3
# 7 is a prime number
# 8 equals 2 * 4
# 9 equals 3 * 3

continue는 break문처럼 반복문 전체를 탈출하는게 아닌, 다음 요소로 넘어갈 때 사용하는 키워드입니다.

while 문

while도 for 처럼 반복문으로 사용됩니다. 조건이 참일 경우 반복하는 반복문입니다.

a = 0
result = 0
while a < 10:
    result += a
    a += 1
print("sum :", result)

마찬가지로 break,continue를 사용할 수 있습니다.

[자바/Java] Optional 개념, 사용

효기로그 — Wed, 3 Jun 2020 13:06:20 +0900

해당 내용은 책 모던 자바 인 액션의 내용을 참고해서 작성하였습니다.

등장 배경

Java를 통해 개발을 진행하다 보면, 해당 객체의 참조 값이 null인지 아닌지 체크하는 분기문이 생기는데, 이와 같은 분기문의 경우 코드의 가독성이 떨어지고, 해당 객체가 null을 가질 수 있는 객체인지, 필수 값인지 직관적으로 알 수 있는 방법이 없어서 에러의 근원이 되는 문제가 발생했기 때문에, 선택형값을 캡슐화하는 클래스 Optional을 Java 8에 추가되었다.

Optional 객체 만들기

1. 빈 Optional 객체 만들기

Optionl 클래스의 정적 팩토리 메소드로 아래와 같이 사용 가능

Optional<String> optStr = Optional.empty();

2. null이 아닌 값으로 Optional 만들기

만약 값이 null이라면 바로 NullPointException이 발생하며, 값을 항상 넘겨줘야 한다.

Optional<String> optStr = Optional.of("not null");

3. null 허용 Optional 만들기

null또는 값을 가질 수 있는 Optional을 리턴해준다.

Optional<String> optStr = Optional.ofNullable(null);

Optional 클래스의 메서드

예제를 위해 사용되는 클래스는 아래와 같다.

public class Person {

    private Car car;
    private int age;

    public Optional<Car> getCar(){ return Optional.ofNullable(car); }
    public int getAge() { return age; }
}

public class Insurance {

    private String name;

    public String getName() { return name; }
}

public class Car {

    private Insurance insurance;

    public Optional<Insurance> getInsurance(){ return Optional.ofNullable(insurance); }
}

위와 같은 도메인 모델이 구성되어 있을 때, Car을 기준으로 보면 getCar은 Optional을 리턴하고 getAge는 int형을 리턴해준다. 이렇게 한눈으로 값이 꼭 있어야 하는지, null이 들어갈 수 있는 객체인지 여부를 구체적으로 표현할 수 있는 장점이 있게된다. 또 특이한점은 필드로 옵셔널 객체 즉 private Optional<Car> car 과 같은 방식을 사용하지 않은 이유는 해당 클래스를 설계한 사람이 용도를 선택형 반환값으로 구분을 지었기 때문에 Serializable를 구현하지 않았다. 그래서 직렬화가 필요한 프레임워크나, 도구에서 문제가 생길 수가 있기 때문이다.

메서드의 종류

1. empty, of, ofNullable

Optional 인스턴스를 반환 각각 빈 옵셔널, 널이 아닌 옵셔널, 널을 허용하는 옵셔널 ( 위에 설명이 있기 때문에 생략 )

2. filter

마치 스트림처럼 피리디케이트와 일치하면 값을 포함한 Optional<T>을 리턴, 없으면 empty 옵셔널을 리턴해준다.

Optional.of(new Person()).optPerson.filter(p -> p.getAge() > 19);

위와 같이 사용가능하며, 나이가 19세를 넘어가는 Person인지 필터가 가능하다.

3. map

스트림과 비슷하며, 존재하면 값이 존재하면 매핑 함수를 적용

Optional<String> name = 
                Optional.of(new Insurance()).map(Insurance::getName);

Optional<Optional<Car>> optCar = 
                Optional.of(new Person()).map(Person::getCar);

2개의 map을 사용했으며, optCar의 경우 반환 타입이 옵셔널 안에 옵셔널이 감싸지는 형태로 리턴이 된다. 이유는 Optional.map 자체가 해당 값을 옵셔널로 감싸주는 메서드인데, Person.getCar의 경우 리턴 타입이 Optional<Car>이기 때문이다. 이와 같은 문제로 인해, 바로 아래 flatMap 메서드를 제공해준다.

4. flatMap

스트림과 비슷, 평면화를 위해 사용. 값이 존재하면 제공된 함수를 적용한 결과를 값을 포함한 Optional<T>을 리턴, 없으면 empty 옵셔널을 리턴해준다.

Optional<Insurance> optInsurancer = 
                Optional.of(new Person())
                        .flatMap(Person::getCar)
                        .flatMap(Car::getInsurance);

5. get

Optional이 감싸고 있는 값을 반환하고, 값이 없으면 NoSuchElementException 발생

Optional.empty().get();

위에는 빈 옵셔널에 get메서드를 호출하기 때문에 NoSuchElementException이 발생한다.

6. isPresent

값이 존재하면 true, 빈 옵셔널이면 false

Optional.ofNullable(null).isPresent();
Optional.ofNullable("not null").isPresent();

위 첫번 째 결과는 false, 두번째는 true를 반환

7. ifPresent ,ifPresentOrElse

ifPresent의 경우 값이 존재하면 지정된 Consumer를 실행하고, 없으면 아무동작도 안함
ifPresentOrElse은 java 9에 추가 되었으며, 추가로 Runnable 인터페이스를 넘겨준다. 값이 존재하면 지정된 Consumer를 실행하고, 값이 없으면 넘겨받은 Runnable를 실행

// 첫번째 실행 안하고 not null만 출력
Optional.ofNullable(null).ifPresent(System.out::println);
Optional.ofNullable("not null").ifPresent(System.out::println);

// 무언가동작, not null 2개의 문장 출력
Optional.ofNullable(null).ifPresentOrElse(System.out::println, () -> System.out.println("무언가 동작"));
Optional.ofNullable("not null").ifPresentOrElse(System.out::println, () -> System.out.println("무언가 동작"));

8. or

값이 존재하면 같은 Optional<T>을 리턴, 없으면 Supplier에서 만든 Optional<T>을 리턴

Optional.ofNullable(null).or(() ->(Optional.of("UnKnown")));
Optional.ofNullable("not null").or(() ->(Optional.of("UnKnown")));

각각 Optional<String>를 리턴해주며, 첫번째는 "UnKnown"이라는 값을 가진 옵셔널을 두번째는 "not null"이란 값을 가진 옵서녈을 리턴해준다.

9. orElse

값이 존재하면 값을 리턴, 없으면 인자로 제공된 기본값을 반환

Optional.ofNullable(null).orElse("UnKnown");

or 메서드와 다르게 바로 값을 반환해주며 해당 예제는 String 타입의 "UnKnown"을 리턴해준다

10. orElseGet

값이 존재하면 값을 리턴, 없으면 Supplier에서 제공되는 값을 반환

Optional.ofNullable(null).orElseGet(() -> new String("UnKnown"));

11.orElseThrow

값이 존재하면 값을 리턴, 없으면 Supplier에서 생성한 예외를 발생

Optional.ofNullable(null).orElseThrow(NullPointerException::new);

예제에서는 NullPointException을 사용했는데, 이러면 Optional을 사용하는 의미가 없기 때문에, 필요하다면 사용자 정의 Exception 또는 기존에 정의된 Exception중 필요한걸 찾아서 넘겨주면 된다.

12. stream

값이 존재하면 존재하는 값만 포함하는 스트림을 반환하고, 없으면 empty 스트림 반환

Optional.ofNullable(null).stream();

기본형 특화 옵셔널

스트림처럼 기본형 int, long, double 전용 옵셔널이 존재하지만. 스트림의 경우 요소가 여러개이기 때문에 오토박싱에 대한 비용을 감소시켜서 성능 향상의 효과가 있었지만, 옵셔널의 경우 요소의 수는 한개이므로 성능향상은 존재하지 않는다. 또한 map, flatMap, fillter 등을 지원해주지 않고, 기존의 Optional과 혼용으로 사용이 불가능 하기 때문에 기본형 특화 옵셔널 사용을 하지 말아야 한다.

[Java/java] 스트림과 컬렉터 Stream, Collector

효기로그 — Tue, 26 May 2020 16:02:06 +0900

해당 내용은 모던 자바 인 액션의 내용을 참고해서 작성하였습니다.

스트림

스트림은 람다와 마찬가지로 자바8에서 추가된 기능이다. 여기서 스트림이란, 데이터 처리 연산을 지원하도록 소스에서 추출된 연속된 요소로 정의할 수 있다.

스트림과 컬렉션

스트림도 컬렉션과 마찬가지로 연속된 값 집합의 인터페이스를 제공한다. 단 데이터를 언제 계산하느냐가 컬렉션과 스트림의 가장 큰 차이. 컬렉션은 현재 자료구조가 포함하는 모든 값을 메모리에 저장하는 자료구조이다. 그 후, 계산이 가능하다. 그러나 스트림의 경우 요청할 때만 요소를 계산하는 고정된 자료구조이다.
이를 동영상으로 비유하면, 컬렉션은 동영상을 모두 다운로드 후에 볼 수 있고, 스트림의 경우 전체가 아닌 해당 구간만 다운받아서 볼 수 있는 스트리밍 서비스가 있다. 또한 스트림은 한번 사용하면 소멸된다. 재사용이 불가능

또한 스트림은 내부 반복으로써 컬렉션과 같이 ( forEach ) 문등을 통해 반복을 컨트롤 할 필요가 없다. 이를 외부 반복이라 한다. 또한 스트림은 내부 반복을 사용하기 위해, filter, map 등과 같은 다양한 추가 연산자를 제공해준다.

스트림의 연산

스트림은 내부 반복을 위해 파이프라인과 다양한 추가 연산자를 제공해준다. 이런 연산을 크게 2가지로 나눌 수 있는데 중간 연산 과 최종 연산으로 구분할 수 있다.

중간 연산 : 중간 연산의 특징은 단말 연산을 스트림 파이프라인에 실행하기 전까지 아무 연산도 수행하지 않는다. 즉 게으르다는 것이다. 중간 연산을 합친 다음에 최종 연산으로 한 번에 처리하기 때문이다. (filter, map, limit, sorted, distinct 등)
최종 연산 : 스트림 파이프라인에서 결과를 도출한다. (forEach, collect, count 등)

위와 같이 스트림의 게으른 특성 덕분에 몇가지 최적화 효과를 얻을 수 있다. limit를 통해 쇼트서킷 또는 서로 다른 연산자를 한 과정으로 병합할 수 있는 루프퓨전 ( filter 과 map을 한 연산에서 둘 다 사용 가능 )

정리하자면 스트림은 질의를 수행한 ( 컬렉션 같은 ) 데이터 소스가 필요하고, 중간 연산, 최종 연산의 형태로 이용이 가능하다.
members.stream().filter(m -> m.getAge() > 20 ).limit(3).forEach(System.out::println)
여기서 members는 데이터 소스, filter,limit는 중간연산, forEach는 최종 연산에 해당한다.

스트림의 활용

1. 필터링

스트림은 filter 메서드를 통해, 프리디케이트를 인수로 받아, 필터가 가능하고, distinct를 통해 고유 요소의 중복을 제거 할 수있다. 여기서 고유 여부는 스트림의 hashCode, equals로 결정됨

2. 스트림 슬라이싱

데이터가 무수히 많은 경우, 특정 조건까지의 리스트만 반환하고 싶은 경우
예제에서 members는 10만건의 멤버를 가지고 있다고 나이순으로 정렬이 되어있다고 가정

자바 9 이상부터는 아래의 2가지 방법을 제공

List<Member> result = members.stream().takeWhile(m -> member.getAge() < 20).collect(toList());

위와 같이 사용하면 20세 미만인 멤버 리스트를 반환해준다. 반대로 20세 보다 큰 사람을 탐색하고 싶은 경우, dropWhile를 사용하면 된다.

또는 간단하게 페이징등의 동작을 위해 정해진 갯수로 제한하고 싶을 경우 limit를 사용할 수 있다.
마지막으로 검색된 요소를 n개 건너 뛰고 싶은 경우 skip를 통해 검색된 스트림에서 n개만큼 컨너뛴 요소를 추출할 수 있다.

3. 매핑

어떤 문자열에서 겹치는 문자를 제외해야 하는 요구조건이 생겨서, String.split("")를 통해 중복을 제거하려고 했다면, 스트림의 map대신 flatMap를 사용해야 한다. 이유는 String.getBytes의 경우 리턴값이 String배열이기 때문에, 해당 배열을 평문으로 만들어줄 필요가 생기기 때문이다.

Arrays.asList("banana","apple").stream()
                .map(s -> s.split(""))
                .distinct()
                .forEach(System.out::println);

해당 코드는 중복제거가 되지 않기 때문에 원하는 결과를 얻을 수 없다. flatMap을 통해 Stream<String배열> 부분을 Stream<String타입>로 변경해준다.즉 스트림의 결과를 쉽게 평면화 해준다.

Arrays.asList("banana","apple").stream()
                .map(s -> s.split(""))
                .flatMap(Arrays::stream)
                .distinct()
                .forEach(System.out::println);

검색과 매칭

스트림은 allMatch, noneMatch, findFirst, findAny등의 연산자를 통해, 검색과 매칭에 효율적으로 처리가 가능해진다. 이는 limit처럼 쇼트서킷을 활용했으며, 해당 기능은 이름대로 수행한다.

allMatch, noneMatch의 경우 프리디케이트가 적어도 일치하냐, 일치하지 않느냐에 대한 수행 결과를 반환해주고,
findFirst, findAny 둘다, 일치하는 첫번 째 항목을 리턴해준다. 둘이 동작이 비슷하지만, 병렬에서는 findAny를 사용하는게 좋으며, 값이 null일 수 있기 때문에 Optional<T>를 리턴해준다.

리듀싱

스트림의 filter을 통해 서울에 사는 멤버들의 리스트를 추출할 수 있게되었다. 나아가 추출 된 멤버들 중 나이가 제일 많은 사람과, 제일 적은 사람을 구하시오와 같은 요구를 처리하기 위해선 모든 요소를 반복적으로 처리해야 하며, 이런 질의를 리듀싱 연산이라고 한다. 아래와 같이 해결할 수 있다.

int max = members.stream()
                    .filter(m -> m.getAge() > 20)
                    .map(Member::getAge)
                    .reduce(0, (a, b) -> a > b ? a : b);

reduce의 0은 초기값이며, 초기값을 생략도 가능한 메소드를 오버로딩해준다. 다만 값이 없을 수도 있기 때문에 Optional로 반환해준다. 나아가 메서드 참조를 통해 아래처럼도 사용 가능

int max = members.stream()
                    .filter(m -> m.getAge() > 20)
                    .map(Member::getAge)
                    .reduce(0, Integer::max);

이렇게 값을 반복적으로 처리하기 위해 내부 상태를 가지고 있어야 하는 스트림을 내부 상태를 갖는 연산 이라고 하며, reduce의 경우 int나 double로 내부 상태로 사용했고, 해당 값은 한정되어 있는 값이다. 또한 소수에서 젤 큰 수를 찾아라와 같은 무한 스트림에서 sorted나 distinct의 경우 값을 비교하기 위해 무한적으로 요소가 버퍼에 추가되어야 하기 때문에 문제가 발생한다. 이렇게 내부 상태를 갖는 연산은 사용 시 주의가 필요하다.

내부상태를 갖는 연산의 종류 : distinct, skip, limit, sorted, reduce

기본형 특화

스트림은 기본적으로 참조 타입을 가지기 때문에, 오토박싱에 대한 비용이 발생하게 되고, 간단한 누계같은 함수를 바로 사용할 수 없다. 그래서 함수처럼 기본형 특화 스트림을 제공해주며, 기본적인 메소드들이 정의되어 있다.( min, max, range, rangeClosed 등 ) 이전에 최대값을 구하는 방식을 아래처럼 변경이 가능하다

OptionalInt max2 = members.stream()
                .filter(m -> m.getAge() > 20)
                .mapToInt(Member::getAge)
                .max();

여기서 리턴타입은 OptionalInt, OptionalDouble등 특화 참조타입으로 리턴을 해준다.
복원의 경우 boxed 메소드를 사용하면 기본 스트림으로 변환해준다.

스트림 만들기

임의의 값으로 만들기

Stream<Integer> stream = Stream.of(10, 20 , 41, 31 ) ;

빈 스트림 만들기

Stream<Integer> stream = Stream.empty();

null이 될 수 있는 객체로 스트림 만들기 return값이 null일때 빈 스트림을 반환해준다.
```
Stream<String> values = Stream.ofNullable(System.getProperty("hmoe"));
```
null이 될 수 있는 객체로 스트림 만들기 return값이 null일때 빈 스트림을 반환해준다.
```
int[] arr = { 1, 2, 3, 4, 5 };
int sum = Arrays.stream(arr).sum();
```
그외 함수로 무한 스트림 만들기 iterate, generate : 둘의 차이는 값을 연속으로 계산하냐, 매번 인수로 받느냐 차이

Collector 컬렉터

스트림 최종연산으로 collect(toList())를 많이 사용했었는데, 이때 collect 메서드는 Collector 인터페이스의 구현을 매개변수로 받는다. 이 인터페이스의 구현은 스트림의 요소를 어떤 식으로 도출할지 지정한다.
또한 유틸성 클래스로 Collector이 있으며 주로 스트림 요소를 하나의 값으로 리듀스하고, 요약하는 기능과 그룹화/분할 3가지로 구분할 수 있다.

1. 스트림 하나의 값으로 리듀싱

컬렉터를 통해서도 리듀싱 기능 즉 요약 연산이 가능하다.

Long count = members.stream().collect(counting());

해당 코드는 아래처럼 요약이 가능하다.

Long count = members.stream().count();

이외 최대 값, 최소 값을 리턴해주는 maxBy(Comparaotr), minBy(comparator)도 제공해주며, 리턴은 Optional<T> 타입으로 반환을 해준다.

또 많이 사용하는 합계와, 평균값을 구해주는 메소드를 제공해주며 각각 averagingInt(mapper),averagingLong(mapper),averagingDouble(mapper) 을 제공해주며, 동작 방식은 동일하고, 요약하는 데이터 형식이 다르다, 마찬가지로 합계도 summingInt(mapper)과 같은 형태로 3가지를 제공한다.

위 합계, 평균, 카운트, 최소, 최대 값을 한번에 모두 리턴해주는 놀라운 메소드도 제공해주며 이름은 summarizingInt(mapper)로 제공주고 리턴으론 각각 요약 데이터 형식에 따른 객체를 리턴해준다.

IntSummaryStatistics result = members.stream().collect(summarizingInt(Member::getAge));

해당 객체는 다음과 같이 값들이 들어있으며 IntSummaryStatistics result = members.stream().collect(summarizingInt(Member::getAge)) 익숙한 getCount등과 같은 방식으로 값을 꺼낼 수 있다.

마지막으로 문자열의 연산도 제공해주는데 joining()이며, 구분자를 주고 싶은 경우 다음처럼 joinging(", ") 매개변수로 넘겨주면 된다.

2. 범용 리듀싱 요약 연산

위에서 사용한 모든 팩토리 메서드는 reducing로 정의해 직접 사용할 수도 있다. 합계의 경우 다음과 같이 사용 가능
가동성이나, 생산성을 따져서 편리하게 사용하는게 좋음

int sum = members.stream().collect(
                reducing(0, Member::getAge , Integer::sum  
            );

또한 예제에서는 Collector을 한개만 사용했는데 진정한 강력함은 다른 Collector과 함께 사용할 때 나타난다.

3. collect 와reduce

둘다 요약 연산을 하며, 결과를 도출해주는 메소드이다. 다만 reduce의 경우 불변 값을 결합하여 새로운 값을 생성하는 연산이고, collect는 컨테이너 를 변경 하여 생성해야하는 결과를 축적 하도록 설계되었습니다.
쉽게 말해, List와 같이 가변 컨테이너 관련 작업이면서, 병렬성을 확보하기 위해선 collect를 사용하는 방법이 바람직합니다.

4. 그룹화

예제에서 성을 기준으로 멤버들을 그룹화하고 싶은 경우 groupingBy를 사용 하면 된다.

Map<LastName, List<Member>> result = members.stream().collect(groupingBy(Member::getLastname));

결과는 다음과 같다 {PARK=[[age=15]], KIM=[[age=41], [age=61], [age=7]], LEE=[[age=23]]}

이제 위 예제에서 성을 기준으로 그룹화하고, 성인인 사람을 필터링하고 싶다면? 아래와 같이 사용할 수 있다.

Map<LastName, List<Member>> result = members.stream()
                                        .filter(m -> m.getAge() > 19)
                                        .collect(groupingBy(Member::getLastname));

결과는 다음과 같다. {LEE=[[age=23]], KIM=[[age=41], [age=61]]}

위에서 잠깐 언급한, collect는 컬렉터를 다른 컬렉터와 사용할 경우 막강한 기능을 제공한다고 소개했었다. 위 2개의 결과는 조금 차이가 있다. 바로 filter에 해당하는 값이 없다면, 최종연산에 포함되지 않기 때문에 성이 PARK 타입은 그룹에서 제외가 되었다. 그래서 아래처럼 변경을 해본다.

Map<LastName, List<Member>> result = members.stream()
                                            .collect(groupingBy(Member::getLastname
                                            ,filtering( m -> m.getAge() > 19, toList())));

결과는 다음과 같이 없는 경우에도 버킷을 생성한 결과를 리턴해준다. {PARK=[], KIM=[[age=41], [age=61]], LEE=[[age=23]]}

위처럼 동작하는 이유는 collec가 최종 연산에 해당하기 때문에, 스트림의 결과에서 그룹화, 필터링을 진행하기 때문에 다른 연산 결과를 보여준다. 여기서 filtering를 썻다는거는 groupingBy도 사용 가능하다는 뜻이고, 다음과 같이 다수준으로 그룹화가도 가능해진다.

Map<LastName, Map<Object, List<Member>>> result = members.stream()
                    .collect(groupingBy(Member::getLastname,
                            groupingBy(m -> {
                                if(m.getAge() > 19) return AgeGroup.ADULT ;
                                else return AgeGroup.CHILD;
                                }
                            )));

결과는 {LEE={ADULT=[[age=23]]}, PARK={CHILD=[[age=15]]}, KIM={CHILD=[[age=7]], ADULT=[[age=41], [age=61]]}}

이렇게 외부 컬렉터로 넘겨주는 컬렉터에는 제한이 없이, 다 사용이 가능하다는 강점이있다.

5. 분할

분할 함수라 불리는 프리디케이트를 분류 함수로 사용하는 특수한 그룹화 기능으로, Boolean 값 결과를 토대로 그룹화를 한다. 다음과 같이 사용할 수 있다.

Map<Boolean, List<Member>> result = 
                                members.stream()
                                    .collect(partitioningBy(
                                        m -> m.getLastname().equals(KIM)
                                    ));

결과는 {false=[[age=23], [age=15]], true=[[age=41], [age=61], [age=7]]}

[자바/Java] Lambda 람다 표현식, 함수형 인터페이스

효기로그 — Fri, 22 May 2020 10:08:45 +0900

해당 내용은 모던 자바 인 액션을 참고해서 작성한 내용입니다.

람다란 무엇인가

람다 표현식은 메서드로 전달할 수 있는 익명 함수를 단순화한 것이라고 할 수 있다. 람다 표현식에는 이름은 없지만, 파라미터나 리스트, 바디, 반환 형식, 발생할 수 있는 예외 리스트는 가질 수 있다. 이러한 람다는 아래 4가지의 특징을 가진다.

익명 : 메서드와 다르게 이름이 없으므로 익명이라고 표현한다.
함수 : 람다는 메서드처럼 클래스에 종속되지 않아 함수라고 부른다.
전달 : 람다 표현식을 메서드의 인수로 전달하거나 변수로 저장 가능
간결성 : 많은 코드를 줄일 수 있다.

아래는 람다의 기본 구조이다
(Member m1, Member m2) -> m1.getName().compareTo(m2.getName());

위 예제처럼 람다는 { } 와 return 문을 명시적으로 사용하지 않아도 된다. 하지만 람다 표현식 안에서 여러줄을 사용할 때는 { }를 사용해야 하며, 리턴이 있는 경우 return문을 명시적으로 선언해줘야 한다.

(int x, int y) -> { 
    System.out.println("x + y ");  
    System.out.println(" = " + (x + y)); 
    return x + y ; 
  }

람다의 사용

람다는 그렇다면 어디에 사용할 수 있는 건가? 모든 코드를 람다로 변화 할 수 있는건가? 답은 아니다. 바로 함수형 인터페이스라는 문맥에서만 람다 표현식을 사용할 수 있다.
함수형 인터페이스란 하나의 추상 메서드를 지정하는 인터페이스이다. 더 많거나, 적어도 안된다. 여기서 자바 언어 설계자들은 시대의 변화에 따라 함수라는 타입을 새로 만드는 방법 대신, 자바 개발자들에게 익숙한 인터페이스를 활용해 다른 언어의 함수처럼 사용할 수 있게 만드는 방법을 제공했다.

추가로 @FunctionalInterface 어노테이션을 제공, 선언 된 인터페이스가 함수형 인터페이스가 아니면 컴파일 오류가 발생하게 기능을 추가했다.

함수형 인터페이스 사용

자바 8부터는 java.util.function 패키지로 여러 가지 함수형 인터페이스를 제공해주며. 그 중에 Predicate 함수형 인터페이스를 통해 람다의 사용법 예제를 본다.

@FunctionalInterface
public interface MemberPredicate {
     boolean test(Member member);
}

public static List<Member> filter(List<Member> members, MemberPredicate mp) {
        List<Member> result = new ArrayList<>();
        for(Member member : members) {
            if(mp.test(member)) { 
                result.add(member);
            } 
        }
        return result;
    }

위와 같은 예제가 존재한다고 가정하고, 물론 제네릭을 통해 더 재사용성이 높은 코드를 만들 수 있지만, 이전의 다른 포스팅의 예제를 사용하기 때문에 위에처럼 선언했다. 아래는 사용 방법이다.

MemberPredicate memberPredicate = (Member m) -> LEE.equals(member1.getLastName());
List<Member> result = filter(members, memberPredicate);

위에 처럼 사용 가능하며 더 코드를 줄인다면 List<Member> result = filter(members, (Member m) -> LEE.equals(m.getLastname())); 와 같이 선언해 사용할 수 있게 된다.

기본형 특화

자바는 모두 알다시피 참조형 또는 기본형으로 구성되어 있다. 그런데 public interface Predicate<T> { boolean test(T T); } 와 같이 선언된 함수형 인터페이스의 경우 기본형으로 사용하고자 할 때 불필요하게 오토박싱이 일어나 메모리를 낭비하거나, 메모리 탐색등의 과정이 추가로 필요하게 된다.

그래서 자바는 기본적으로 기본형 특화 함수형 인터페이스를 제공해준다. public interface IntPredicate { boolean test(int t);}와 같이 해당 인터페이스들은 종류가 많기 때문에, 그냥 기본형만 사용할 경우 기본형 특화 인터페이스를 사용 할 수 있다는 것을 알고 필요하면 직접 구현 또는, Java API를 참조 하면 될 것 같다.

예외 사용법

함수형 인터페이스의 함수도 일반 메서드처럼 예외를 사용할 수 있다고 설명했다. 직접 구현한 경우 문제가 되지 않는다 가령, 아래처럼 말이다.

@FunctionalInterface
public interface MemberPredicate {
     boolean test(Member member) throws Exception;
}

그러나 좀 전에 설명한 Java에서 제공해주는 기본 함수형 인터페이스의 경우 내 마음대로 인터페이스를 수정할 수 없다는 문제점이 생긴다. 그래서 명시적으로 throw new Exception() 을 발생시켜 원하는 예외처리를 할 수 있다.

람다의 형식 추론, 지역 변수

제너릭의 다이아몬드 연산자가 가능한 것 처럼 List<Member> members = new ArrayList<>() 에서의 <> 람다도 형식을 추론해 코드를 더욱 간결하게 만들 수 있다.
List<Member> result = filter(members, (Member m) -> LEE.equals(m.getLastname())); 앞서 사용한 예제 코드중 한 부분이며, 이를 다음처럼 코드를 줄일 수 있다. List<Member> result = filter(members, (m) -> LEE.equals(m.getLastname()));

람다는 지역 변수를 사용할 수 있다. 다만 지역 변수의 경우 값을 변경할 수 없다는 제약이 존재한다. 이는 동작 방식의 메커니즘에 의해서 제약이 생기게 되는데 자세한 내용은 추가로 검색하길 바란다.

메서드 참조

메서드 참조를 이용하면 기존의 메서드 정의를 재활용해서 람다처럼 전달할 수 있다. 아래가 예시이다.
members.sort((Member m1, Member m2) -> m1.getAge().compareTo(a2.getAge())) 를 메서드 참조를 사용하면
members.sort(Comparator.compareTo(Member::getAge)로 줄일 수 있게 된다. 이러한 메소드 참조를 만드는 3가지 방법은 아래와 같다.

정적 메서드 참조 : Integer의 parseInt는 Integer::parseInt
인스턴스 메서드 참조 : String의 length는 String::length
개존 객체의 인스턴스 메서드 참조 : Member객체의 인스턴스 member의 getAge는 member::getAge

람다와 메서드 참조 단축 표현 예제

( Member member ) -> member.getName()           //  Member::getName
( String str, Integer i ) -> str.substring(i)   // String::substring
( String str ) -> System.out.println(str)       // System.out::println
( String str ) -> this.isValidStr(str)          // this::isValid

위 예제들과 같이 메서드 참조를 사용하게 되면 가독성을 높일 수 있게 된다는 큰 장점이 생긴다.

생성자 참조

ClassName::new 처럼 클래스명과 new 연산자를 통해 메서드 참조처럼 기존 생성자의 참조를 만들 수 있다. 마치 메서드 참조의 정적 메서드 참조를 만드는 방법과 비슷하다.

예를들어 매개변수가 없는 기본 생성자가 존재하는 Member 클래스가 있다고 가정했을 때, 아래와 같이 사용 가능
Supplier<Member> m1 = Member::new Supplier 함수형 인터페이스는 매개변수 없이 T 타입을 리턴하는 () -> T 형식의 시그니처를 가진기 때문에 이처럼 사용이 가능하다.

그렇다면 생성자에 매개변수를 가지는 경우는 어떻게 사용할까? 바로 Function 함수형 인터페이스를 사용하면 편하게 사용이 가능하다. Member 클래스는 생성자가 나이를 매개변수로 받는다고 가정한다.

Function<Integer, Member> f = Member::new;
Member member = f.apply(28);

위처럼 선언하면 28이라는 나이를 가진 새로운 맴버 객체를 생성하게 된다. 그렇다면 매개변수가 2개인 경우는? 다행히 BiFunction 함수형 인터페이스의 경우 ( T, U ) -> R 형식의 시그니처를 가지기 때문에 활용이 가능하다. 더 나아가, 3개 이상이거나 가변적일 경우는? 새로운 함수형 인터페이스를 선언하면 문제는 해결이 된다.

public interface TriFunction<T, U, V, R> {
    R apply ( T t, U u, V v );
}

디폴트 메서드와 메서드의 조합

아래와 같은 이름을 가지는 리스트가 있을 존재한다고 가정한다.

List<Member> members = Arrays.asList(
                    new Member(23),
                    new Member(15),
                    new Member(41),
                    new Member(61),
                    new Member(7)
                );

이때, 나이순으로 정렬을 원하는 요구가 생길 경우 아래와 같이 정렬을 쉽게 할 수 있다.

members.sort(Comparator.comparing(Member::getAge))

그런데 여기에서 결과를 내림차순으로 보고 싶다고 하면 또 다른 Comparator 인터페이스를 생성할 필요 없이, 간단하게 반전된 결과를 얻을 수 있게 된다.

members.sort(Comparator.comparing(Member::getAge).reversed())

그런데 처음 위 예제를 봤을 때 뭔가 불편한 느낌을 받았었다. 람다를 사용할 수 있다는 것은, 함수형 인터페이스라는말이고, 함수형 인터페이스는 1개의 추상 메서드를 가지는 메서드라고 배웠는데, 여기서 comparing가 해당하는 추상 메서드인건 알겠다.
그럼 reversed() 메서드는 무엇인가? 바로 자바8에 새로 추가된 디폴트 메서드이다. 디폴트 메서드는 추상 메서드가 아니기 때문에, 위와 같이 함수형 인터페이스에 선언이 가능하고 사용이 가능하다.

추가로 Comperator에는 thenComparing를 제공한다. 해당 메소드는 기존의 정렬 기준이 동일 할때 즉, 예제에선 나이가 같은 사람들이 있을 때, 추가로 조건을 줄 수 있게 해주는 메소드이다.

Predicate, Function 의 디폴트 메소드

Predicate 인터페이스의 경우도 결과를 반전시켜주는 negate(), or과 and 연산을 위한 or, and도 제공해준다.
Function 인터페이스의 경우 andThen , compose를 제공하며, andThen의 경우 결과를 전달, compose의 경우 인수로 주어진 함수를 먼저 실행한 후에 실행 f.andThen(g) -> f 실행 후 g 실행, f.compose(g) g 실행 후 f 실행

함수형 인터페이스의 종류

기본형 특화를 제외한 큰 분류의 함수형 인터페이스만 소개하겠습니다.

함수형 인터페이스	함수 디스크립터	디폴트 메소드
Predicate<T>	T -> boolean	and(Predicate<? super T> other) - && 연산자와 대응 or(Predicate<? super T> other) - \|\| 연산자와 대응 negate() - ! 연산자와 대응 ( 반전 )
Consumer<T>	T -> void	andThen(Consumer<? super T> after) : 후 처리 연결
Function<T, R>	T -> R	andThen(Function<? super R, ? extends V> after ) : 후 처리 연결 compose(Function<? super R, ? extends V> after ) : 전처리 ( 인자로 받은 function을 먼저 실행 )
Supplier<T>	( ) -> T
UnaryOperator<T>	T -> T
BinaryOperator<T>	( T, T ) -> T
BiPrdecate<T, U>	( T, U ) -> boolean	and(BiPrdecate<? super T, ? super > other) - && 연산자와 대응 or(BiPrdecate<? super T, ? super> other) - \|\| 연산자와 대응 negate() - ! 연산자와 대응 ( 반전 )
BiConsumer<T, U>	( T, U ) -> void	andThen(BiConsumer<? super T, ? super U> after) : 후 처리 연결
BiFunction<T, U, R>	( T, U ) -> R	andThen(BiFunction<? super R, ? extends V> after ) : 후 처리 연결

스태틱 메소드나, 기본형 특화에 대한 참고를 원하시는분은 링크를 클릭해서 확인하시길 바랍니다. ( java 8 기준 )

[Java/자바] 람다의 사용, 동작을 파라미터화

효기로그 — Thu, 21 May 2020 13:56:13 +0900

요구사항의 변화

소비자의 요구사항은 언제든지 변할 수 있기 때문에, 변화에 조금 더 유연한 방식이 필요하게 되었다.
예를 들어, 처음에는 성이 'LEE'인 사람들만 추출해주는 되는 프로그램이 있다고 가정했을 때, 갑자기 소비자가 성이 'LEE'이고, 나이가 28살 이상인 사람들의 리스트를 추출해주세요. 라고 요구사항이 변경 될 경우 어떠한 방법으로 해결할 수 있는지 예제를 통해 알아보겠습니다.

해당 내용은 Mordern Java in Action 책의 내용을 참고하여 작성하였습니다.

1. 이름에서 성을 기준으로 필터링

첫 요구사항처럼 멤버 리스트에서 성이 LEE인 사람들을 필터링 하는 코드를 아래처럼 작성할 수 있습니다.

public static List<Member> filterByLastNameLee(List<Member> members) {
        List<Member> result = new ArrayList<>();
        for(Member member : members) {
            if(LEE.equals(member.getLastname())) { 
                result.add(member);
            } 
        }
        return result;
    }

위와 같은 코드를 작성했을 경우, 성이 고정적으로 LEE 타입인 사람만 필터링이 가능하다는 문제점이 생깁니다. 여기서 만약 KIM으로도 필터링을 하고 싶다는 요구사항이 생긴다면 우리는 성을 고정으로 LEE 타입으로 두는게 아닌, 파라미터로 받는 방법으로 해결 할 수 있습니다.

2. Lastname을 파라미터화

public static List<Member> filterByLastNameLee(List<Member> members, Lastname lastname) {
        List<Member> result = new ArrayList<>();
        for(Member member : members) {
            if(lastname.equals(member.getLastname())) { 
                result.add(member);
            } 
        }
        return result;
    }

위와 같이 작성하게 되면, 성에 대해서는 유연성을 가지는 메소드를 가지게 되었습니다. 여기에 성이 아닌 나이로 조건을 주는 요구사항이 생기면 추가로 메소드의 수정이 필요하게 됩니다.

3. 나이로 필터링 추가

우리는 멤버의 성에 대해서는 유연한 메소드를 가지고 있습니다. 하지만 또 다시 어떤 조건보다 큰 나이를 가지는 사람이라는 요구 사항이 추가될 경우 동일하게 기존의 메소드를 살짝 변경해 파라미터를 추가해줍니다.

public static List<Member> filterByLastName(List<Member> members, LastName lastname, int age) {
        List<Member> result = new ArrayList<>();
        for(Member member : members) {
            if(lastname.equals(member.getLastname()) && age < member.getAge()) { 
                result.add(member);
            } 
        }
        return result;
    }

하지만 아직 문제점이 발생합니다. 점점 파라미터가 많아지기 시작했고, 추가로 둘다 말고, 어떨때는 성으로만, 어떨 때는 성과 나이로 조건을 주고 싶어요 등의 요구사항이 생기게 됩니다.
해결 방안으로 별도의 메소드를 분리하거나, 최악이지만 플래그용 boolean 변수를 선언해서 조건을 컨트롤 하는 방식으로 할 수도 있을 것입니다. 뭐가 되었든, 중복이 발생하거나, 최악의 코드가 되는건 마찬가지입니다.

4. 인터페이스를 통해 동작 파라미터화 ( 전략 패턴 )

여러 요구사항에 대응하기 위해 동작(조건)을 추상적으로 해결하는 방법을 사용합니다. 바로 디자인패턴의 전략패턴을 활용해서 필요에 따라 선택하는 방식입니다.

public interface MemberPredicate {
     boolean test(Member member);
}

public class MemberLeeLastNamePredicate implements MemberPredicate{

    @Override
    public boolean test(Member member) {
        return LEE.equals(member.getLastname());
    }
}

public class MemberKimLastNamePredicate implements MemberPredicate {

    @Override
    public boolean test(Member member) {
        return KIM.equals(member.getLastname());
    }
}

public static List<Member> filter(List<Member> members, MemberPredicate mp) {
        List<Member> result = new ArrayList<>();
        for(Member member : members) {
            if(mp.test(member)) { 
                result.add(member);
            } 
        }
        return result;
    }

위와 같이 인터페이스와, 구현 클래스를 추가해주고, 기존의 메소드를 변경해주면, 이제 조건 동작 자체를 파라미터화 할 수 있게 되고, 아래와 같이 필요한 전략을 사용해서 원하는 조건을 선택할 수 있게 됩니다.

List<Member> leeMembers = filter(members, new MemberLeeLastNamePredicate());
List<Member> kimMembers = filter(members, new MemberKimLastNamePredicate());

이제 동작이 달라도 파라미터도 안늘어나고, 비슷한 메소드 중복이 제거 되었으니 끝일까? 아쉽지만, 마찬가지로 새로운 요구조건이 생기면 추가로 클래스를 정의를 해야하거나, 사용할 때 인스턴스화 해야하는 번거로운 작업이 남아있습니다.

5. 익명 클래스와 람다

똑똑하신 분들은 그럼 구현체를 만들지말고 사용할때 익명 클래스를 사용하면 되지 않을까? 라는 생각을 하셨을겁니다.

List<Member> result1 = filter(members, new MemberPredicate() {
            @Override
            public boolean test(Member member) {
                return PARK.equals(member.getLastname());
            }
        });

        List<Member> result2 = filter(members, new MemberPredicate() {
            @Override
            public boolean test(Member member) {
                return LEE.equals(member.getLastname());
            }
        });

이제 원하는 방식으로 동작을 구현해서 사용을 할 수가 있습니다. 그러나 코드가 상당히 길어지고 메소드의 기본 구조가 되는 코드가 @Override public boolean test(Member member) {} 불필요하게 반복 됩니다.

여기서 어차피 메소드의 반환타입, 메소드명, 파라미터등 기본 기조는 정해져 있으니까 컴파일 시점에서 추론을 할 수 있지 않을까 해서 생략을 가능하게 기능을 자바8에서 추가가 되었습니다. 바로 람다입니다.
이제 위 코드를 람다로 변환하면 아래와 같이 사용할 수 있습니다.

List<Member> result1 = filter(members, (m) -> LEE.equals(m.getLastname()));
List<Member> result2 = filter(members, (m) -> LEE.equals(m.getLastname()));

위 익명 클래스를 사용한 방식과 동일한 수행 결과를 반환합니다. 이러한 방식을 지원하기 위해 java는 8버전부터 람다, 함수형 인터페이스 제공등 다양한 변화가 생겼습니다.

나아가서 filter메소드의 List<Member> 부분도 List<T> 과 같이 제네릭을 사용하게 되면 타입에 제한 없이 사용 가능한 메소드로 만들 수 있게 됩니다.

6. 디자인패턴 리팩토링

예제에서는 전략 패턴을 예제로 사용했습니다. 전략 패턴 외 템플릿 메서드, 옵저버, 역할 사슬 체인, 팩토리 등에서도 람다로 변환해서 사용할 수 있습니다.

[자바/java] 지네릭스 & 와일드 카드

효기로그 — Fri, 15 May 2020 10:24:57 +0900

지네릭스(Generics)

지네릭스는 다양한 타입의 객체들을 다루는 메서드나 컬렉션 클래스에 컴파일 시의 타입체크를 해주는 기능이다. 객체의 타입을 컴파일 시에 체크하기 때문에 객체의 타입 안정성을 높이고 형변환의 번거로움이 줄어든다.
쉽게 말해 타입을 명시함으로써 타입에 대한 안정성과, 번거로운 형변환을 줄여주는 기능이다. 그리고 지네릭은 클래스와, 메소드에 선언이 가능하다.

지네릭 클래스

Java의 지네릭 클래스인 ArrayList 클래스를 참고해보자 내용은 Oracle 홈페이지의 JDK 11의 API의 내용입니다.

public class ArrayList<E> extends AbstractList<E>
            implements List<E>, RandomAccess, Cloneable, Serializable {
    // 기타
}

위에처럼 클래스에 선언된 지네릭을 지네릭 클래스라 하며, 사용법은 클래스이름<T>과 같은 방법으로 사용이 가능하다.
ArrayList는 지네릭 안에 <E>라는 문자가 들어갔고 설명에서는 <T>가 들어갔는데 여기서 E나 T는 임의의 타입을 선언하는 문법으로써 수학의 x, y, z 등으로 선언하는 것과 비슷하다고 생각하면 됩니다.

이제 간단하게 클래스를 하나 선언과 구현을 해보겠습니다.

public class Item<T> {

    private T item;
    public Item(T item) { this.item = item; }
    public T getItem() { return item; }
}

// 실행
public class Main {
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Item<String> stringItem = new Item<>("Lee");
        System.out.println(stringItem.getItem());

        Item<Integer> intItem = new Item<>(20);
        System.out.println(intItem.getItem());
    }
}

여기서 Item 클래스는 T 라는 타입문자 말고 구체적인 클래스를 선언해서 해당 클래스만 받도록 강제화할 수 있습니다. 예를들어 class Item<String>로 선언하면 String 타입만 사용할 수 있게 됩니다.

지네릭 클래스의 제한

static 멤버에 타입 변수 T를 사용할 수 없다. 그 이유는 타입변수는 인스턴스 변수로 간주되기 때문에 인스턴스 되기 전까지 타입을 알 수 없기 때문이다.
new 연산자의 경우도 마찬가지이다 그래서 동적으로 객체를 생성하는 newInstance()등과 같은 메소드로 생성하는 방법이 있다.

자 그렇다면 객체지향의 특징인 상속 관계에서는 어떻게 사용해야 할까? 기존의 Item 클래스를 조금 변경하고, Book, JavaBook를 추가해줍니다.

public class Item<T> {

    private List<T> list = new ArrayList<T>();

    public List<T> getList() {
        return list;
    }
}

public class Book { }

public class JavaBook extends Book { }

이제 메인 메소드에서 Item<Book> book = new Item<Book>(); 과 같이 선언해보면 당연히 컴파일 오류가 발생하지 않는다. 그럼 다음과 같이 상속관계인 클래스를 사용해보자 Item<Book> javaBook = new Item<JavaBook>(); 얼핏 보면 될거 같지만 컴파일 오류가 발생한다. 이유는 타입을 Book 클래스 타입으로 강제화 했기 때문에 new Item<JavaBook>() 부분이 불가능한 것. 그래서 앞에 선언되는 타입과 뒤에 new 연산자 부분의 타입이 일치하니 java 1.7 부터는 new 연산자 부분에 타입이 생략이 가능해졌다.

타입 변수 T의 타입 제한

그렇다면 T로 선언하면 결국 모든 타입을 다 받을 수 있는거 아니야? 라고해서 제한을 주기 위해 extends 라는 키워드를 제공해서 해당 클래스의 상속 관계인 클래스만 타입을 넣을 수 있도록 제공을 해준다.

public class Item<T extends Book> { }

public class Book { }

public class JavaBook extends Book { }

public class Drink { }

위와 같은 클래스가 존재한다고 할 때 Item<Book> book = new Item<>() 나 Item<JavaBook> javaBook = new Item<>()는 사용이 가능하지만, Book 클래스와 관계가 없는 Drink는 사용이 불가능하다 Item<Drink> drink = new Item<>(); 사용 불가,

추가로 인터페이스의 구현을 해야 한다는 제약이 필요하면 마찬가지로 implements가 아닌 extends 키워드를 사용하고 여러개일 경우 &라는 키워드로 연결해주면 된다 . public class Item<T extends Book & List> { }

와일드 카드

기존의 Item을 매개변수로 받는 static 메소드를 가지는 클래스를 하나 생성해보자.

public class Printer {    
    static void printItem(Item<Book> item) {
        System.out.println("Book 타입의 item");
    }
    static void printItem(Item<JavaBook> item) {
        System.out.println("JavaBook 타입의 item");
    }
}

여기서 Item 자체는 extends란 키워드를 사용해서 상속 관계의 제한을 걸어둔 상태이다. 그러면 현재 Item은 Book 타입과 JavaBook 타입 둘다 가질 수 있는 상태인데, 해당 메서드는 Book 타입만 지원을 한다. 그렇다면 메소드 오버로딩을 사용해서 아래와 같이 추가하면 해결이 될까? 안타깝게도 지네릭만 다르다고 오버로딩은 성립되지 않는다. 그래서 등장한게 와일드 카드라는 개념이다.
?라는 기호로 사용하면 해당 지네릭은 어떤 타입도 될 수 있다는 표현이다.

기존의 메소들를 아래와 같이 변경 static void printItem(Item<?> item) { } 와일드 카드도 제한을 줄 수 있는 키워드를 제공 하는데 extends와 super이다 각각 본인과 자손, 본인과 조상들까지 제한을 걸 수 있다.

제너릭 메서드

메소드의 반환 타입앞에 타입 변수 를 선언하는 메서드를 말한다
static <T> void sort(List<T> list, Comparator< ? super T > c ) 여기서 매개변수의 T와 메소드에 선언된 T는 별개의 타입 변수란 점을 기억해야 한다.

[JAVA/JPA] 값 타입

효기로그 — Mon, 13 Apr 2020 23:11:38 +0900

해당 내용은 인프런의 자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한 의 내용을 기반으로 정리해서 작성한 글입니다.
자세한 내용은 해당 강의 또는 책을 구매하시는걸 추천합니다.

JAP는 크게 값 타입을 2종류로 분류한다.

엔티티 타입 -> Entity로 정의된 객체 , 데이터가 변해도 식별자로 지속해서 추적 가능
값 타입 -> int, Integer처럼 단순히 값으로 사용되는 기본 자료형 또는 래퍼클래스 또는 String

값 타입 분류

기본 값 타입
1. 자바 기본 타입 int float
2. 래퍼 클래스 Integer Double Float
3. String
임베디드 타입
1. 좌표를 묶어서 쓰고 싶은 값 ex)포지션 클래스 -> 포지션 클래스 자체를 값 처럼 쓰는걸 임데디드 타입
컬렉션 타입 -> java 컬렉션

기본값 타입

String name, int age
생명주기를 엔티티의 의존
값 타입은 공유 x ex) int a = 10 ; int b = a; 일때 a = 30 으로 변경 해도 b는 10 그대로
래퍼 클래스는 공유는 가능하나, 기본적으로 java에서는 값을 변화시킬 수가 없기 때문에 변경이 불가능함 사이드 이펙트 발생 x

임베디드 타입 ( 복합 값 타입 )

새로운 값 타입을 정의할 수 있음 이를 JPA는 임베디드 타입이라고 함
주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
int, String과 같은 값 타입의 모음

예제로 멤버는 이름 아이디 근무시간 (startDate, endDate)를 묶고 주소 (address, zipCode, city ) 등을 묶은 임베디드 타입을 만들 수 있다

장점 : 재사용, 높은 응집도, Period.isWokr() 처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음

임베디드 타입을 포함한 모든 값 타입은, 값 타임을 소유한 엔티티에 생명주기를 의존함, 기본 생성자가 필수

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name

    // 기간 
    @Embedded // 해당 어노테이션은 생략 가능하나,유지보수 측면에서 사용을 권장 해당 클래스만 보고 임베디드 타입인지 알 수 있음
    private Period workPeriod;

    // 주소
    @Embedded
    private Address homeAddress
}

// 값 타입은 @Embeddable를 선언
@Embeddable
public clas Period{

    private LocalDateTime startDate;
    private LocalDateTime endTime;

    public void getWorkTime() {  
        ... ( 근무 시간과 관련된 로직 ) 
    } 
}

위 방식처럼 좀 더 entity를 객체스럽게 테이블 구조와 다르게 역할에 따라 분리하고, 하나의 테이블로 사용 가능
엔티티와 값 타입임을 명시해야 하며 둘 중 한곳에만 해도 되지만 유지보수성 을 위해 둘다 사용을 권장

공통으로 사용 가능

Entity와 마찬가지로 @Column등 사용가능하고, 값 으로 Entity도 가질 수 있다

동일한 Embeded 객체 사용

값으로 동일한 객체를 쓰고 싶은 경우 @AttributeOverride 속성 재정의해서 사용 가능, 필요하면 참고할것

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    @Embedded
    private Address homeAddress // Address 객체 중복

    @Embedded
    private Address workAddress // Address 객체 중복
}

위와 같을 경우 Address를 두번 사용하기 때문에 오류 발생 아래와 같이 새로 매핑을 해줘야 사용 가능

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name

    // 기간 
    @Embedded // 둘중 하나만 써도 되나 유지보수 측면에서 사용을 권장
    private Period workPeriod;

    // 주소
    @Embedded
    private Address homeAddress

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name="city", column=@Column(name = "work_city")), // 이런식으로
    })
    private Address workAddress;
}

정리

임베디드 타입은 엔티티의 값일 뿐이다.
임베디드 타입을 사용해도 매핑되는 테이블은 변경이 없다. 그냥 추출일 뿐
공통되는 로직을 재사용할 수 있게 해준다. ex) 좌표 계산이나, 주소를 리턴해주는 로직 등

값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

값 타입 공유 참조
- 임베디드 타입 같은 값 타입은 여러 엔티티에서 공유하면 위험함, 즉 객체이기 때문에 참조 값으로 여러개가 묶일 수 있다. 이럴 경우 참조된 모든 객체에 영향을 주기 때문에 위험
값 타입을 불변 객체로 만든다. String, Integer 처럼...
- setter을 제거하고 getter만 만들어둔다.
- builder 패턴을 통해 객체 생성

값 타입은 동등성 동일성 비교 인스턴스 참조 값 비교 동일성 값 자체 비교는 동등성 -> equals,hash를 모든 필드에 대해서 재정의 해야 함

값 타입 컬렉션

값 타입 자체를 컬렉션에 담아서 사용하는 경우를 말함

@Embedded
private Address homeAdderss;

@ElementCollection
@CollectionTable( name = "addres_history" , joinColumns = @JoinColumn(name = "member_id"))
private List<address> addressHistory ; // 와 같은 형식

@ElementCollection
@CollectionTable( name = "favorite_food" , joinColumns = @JoinColumn(name = "member_id"))
@Column(name = "food_name")
private List<String> favoriteFood ; // 와 같은 형식

이때 테이블은 1:N 이기 때문에 객체에서는 한번에 표현 가능하지만 테이블은 별도의 테이블로 생성이 된다.
이때 favorite_food 같은 경우 필드가 하나일때그냥 @Column 선언가능

이력 테이블용으로 사용이 용이, 기본적으로 지연 로딩, member만 persist해도 전부다 값이 들어감.
왜냐 값타입이기 때문 그냥 Member의 컬럼 취급을 하기 때문

컬렉션도 값타입과 마찬가지로 불변객체여야 한다 side effective가 발생할 확률이 높음
객체를 새로 복사해서 통으로 값을 복사&변경 하던가, 별도의 메소드를 통해서 속성에 접근하는 방식을 구현할 것

값 타입의 컬렉션 변경

값 타입은 엔티티와 다르게 식별자 개념이 없다. 그래서 값은 변경하면 추적이 어렵다
값 타입 컬렉션에 변경 사항이 발생하면 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.
값 타입 컬렉션을 매핑하는 테이블은 키값이 없기 때뭉네, 모든 컬럼을 묶어서 기본 키를 구성해야 함 -> null 입력 x, 중복 저장 x

위와 같이 문제 때문에 관계가 복잡해질 경우, 값 타입 컬렉션 대신 일대다 관계를 고려할 것 ( 엔티티로 값 타입을 빼기 )

@Entity
public class AddressEntity {

    @Id
    Long id

    private Address address;
}

로 변경 후

// Member entity
@OneToMany ( casecade = CascadeType.ALL , orphanRemoval = true)  
@JoinColumn( name = "member_id")
private List<AddressEntity> addressHistory = new ArrayList<>();
// 위와 같이 사용  실무에서 더 사용이 용이함

casecade = CascadeType.ALL 속성의 경우 Member을 저장할 때 AddressEntity 도 같이 저장하는 전파 속성
orphanRemoval = true 는 연관관계가 끊긴 엔티티를 테이블에서도 자동으로 삭제쿼리를 실행하는 속성

결론 : 값 타입 컬렉션 대신 엔티티로 승격해서 사용해라. 엔티티로 만들어야 할지 값 타입인지 잘 구분할것, 식별자가 필요한지 우뮤, 사용할 경우 진짜 단순하게 셀렉트 박스에 치킨, 피자를 멀티로 선택가능한 셀렉트 박스일 경우, 이런 단순한 경우에만 사용, 추적할 필요도 없고 값이 바뀌어도 업데이트 칠 필요가 없는 경우

[JAVA/JPA] 상속관계 매핑

효기로그 — Mon, 13 Apr 2020 14:36:11 +0900

1. 테이블의 상속

상속을 테이블로 구현하기 위해서는 3가지 방법이 존재

조인 전략
싱글 테이블 전략
테이블마다 구현 전략

JPA에서는 기본 전략으로 싱글 테이블을 따름

@Entity public class Item {
    // 필드
 }

@Entity public Book extends Item{
 // 필드
}

실제 테이블 생성 쿼리를 보면 Item, Book 클래스의 필드를 모두 가지는 테이블을 생성

2. 조인 전략

@Entity 
@Inheritance(strategy = InheritanceType.JOINED)
public class Item {
    // 필드
 }

@Entity public Book extends Item{
 // 필드
}

이렇게 사용하면 하위 클래스에 매핑되는 테이블에 자동으로 외래키가 기본키로 생성됨, 정규화되어서 테이블을 생성해준다. 실제 JPA 엔티티 설계와 제일 비슷한 모양으로 테이블이 설계가 됨

그래서 하위 클래스에 값을 넣어도 상위 클래스에도 테이블에도 값이 들어감

    Book book = new Book();
    book.setName("연습용 책");
    book.set...
    ...

위와 같은 로직을 수행하면 Book,Item에 동일한 key 값이 들어가고 각각 맞는 컬럼에 값이 추가된다. 또한 하위 클래스를 셀렉트할 경우 상위 클래스를 조인해서 값을 조회해온다.

추가로 @DiscriminatorColumn(name="사용할 컬럼명") 으로 사용할 경우 부모 테이블에 DTYPE가 자동으로 추가
DTYPE이 있을 경우 ITEM 테이블만 가지고 운영또는 조회할경우 어느 하위 테이블의 타입 객체인지 알 수 있기 때문

DTYPE에 들어가는 이름은 기본적으로 Entity 네임이 들어감 변경하고 싶은 경우, 하위 클래스에서 @DiscriiminatorValue("설정할 값") 으로 설정가능

3. 싱글테이블 전략 ( 기본전략이기도함 )

기본전략으로 나와있기 때문에 설명은 생략. 다만 @DiscriminatorColumn은 필수로 넣어야지 어떤 타입인지 알 수 있기 때문에 필수로 선언할 것, 기본적으로 해당 하위 객체 컬럼의 값이 있냐 없냐등의 로직으로 구분 가능하겠지만 불필요한 작업

타입을 추가해서 해당 테이블의 데이터가 Book인지 Movie인지 즉 어떤 타입인지 알 수 있게 추가가 필요함

테이블당 구현 전략

@Entity 
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item {
    // 필드
 }

@Entity public Book extends Item{
 // 필드
}

하위 클래스를 전부다 테이블로 만드는 전략으로 상위 클래스를 추상클래스로 정의, 전략을 TABLE\_PER\_CLASS로 변경
@DiscriminatorColumn은 의미가 없어서 사용해도 적용안됨 -> 테이블 자체가 구분이 되기 때문

그러나 상위 클래스 즉 ITEM이 없는 테이블이기 때문에 객체지향적으로 ITEM으로 셀렉트할 경우, 모든 테이블을 다 조회 union후 있는 값을 리턴해주는 불필요하고, 어려운 로직이 동작됨. 얼핏 간단하고 쉬워보이지만 단점이 많다.

정리

조인 전략
- 장점
  - 테이블 정규화
  - 외래 키 참조 무결성 제약조건 활용가능
  - 저장공간 효율화
- 단점
  - 조회시 조인을 많이 사용. 성능 저하
  - 조회 쿼리가 복잡
  - 데이터 저장시 insert가 부모 클래스 만큼 동작 ex) 예제에선 2번
단일 테이블 전략
- 장점
  - 조인이 필요x 성능이 제일 빠름, 쿼리가 단순
- 단점
  - 자식 entity 의 컬럼을 모두 null 허용 해야함.. 데이터 무결성에 문제가 생김
  - 오히려 테이블의 컬럼이 너무 많아져서 더 느려질 수 도 있다.
구현 클래스마다 테이블 전략 ( 사용하면 안됨 )
- 장점
  - 테이블 하나하나로 조회할 땐 효과적, not null 제약조건 가능
    - 단점
  - 자식 테이블 관리가 힘들다, 쿼리가 복잡해진다. 유지보수성이 어렵다

@MappedSuperclass

실제 상속이나 DB는 서로 관계가 없지만, 공통으로 들어가는 컬럼을 추가할 때 사용
ex) 등록, 수정, 삭제,수정일, 수정자, 등등이 모든 테이블에 필요하다는 조건이 있을 경우

상속 관계 매핑이 아님, 매핑 정보만 제공 하기 때문에 BaseEntity 조회나 검색이 안됨 (find 사용 불가능), 그래서 추상 클래스로 사용을 권장, 그래야 사용 시점에 해당 클래스를 조작하지 않고 구현체를 조작하기 때문에

@MappedSuperclass
public abstract class BaseEntity{
    @Column(name ="createMemberId")
    private String createdBy;
    private LocalDateTime createdDate;
    private String lastModifiedBy;
    private LocalDateTime lastModifiedDate;

    // 필요하면 getter // setter 추가
}

// 각각의 클래스에 BaseEntity를 상속받는다.
// 단독으로 저장할 필요가 없을 경우 추상 클래스로 구현하는것을 고려!! Itemp이든 BaseEntity처럼 말이다.

정리

상속관계의 매핑이 아니다.
엔티티처럼 @Column등 사용 가능하지만, 엔티티가 아니고, 테이블과 매핑이 되지 않는다.
부모 클래스를 상속 받는 자식 클래스에게 매핑 정보만 제공
조회나, 검색 등 불가, 같은 이유로 직접 사용할 이유가 없기 때문에 추상 클래스로 선언 권장

[독서리뷰] 클린코드

효기로그 — Fri, 3 Apr 2020 14:11:03 +0900

1. 깨끗한 코드

일정? 압박? 어떠한 이유로든 지저분한 코드를 지양하고, 깨끗한 코드를 만들려고 노력하라
깨긋한 코드 : 가독성이 좋으며, 적당히 추상적이며 최소한의 일을 하고 중복이 적어야함

2. 의미 있는 이름

메소드, 변수 클래스 등 이름이라는 방법으로 최소한의 정보를 '정확'하게 전달해야 한다.
여러개의 목록일 경우 실제 list에 담는게 아니라면 accountList 같이 list라는 예약어를 쓰지말고, accounts 등으로 명명
불용어를 피하며, getCustomer(), getCustomerInfo()와 같이 구분이 불분명하게 사용을 피하라
인코딩을 피해라.. 단 인터페이스나 구체 클래스의 경우 imp정도는 사용하는게 가독성이 좋음.
클래스명은 명사나 명사구, Data, Info같은 포괄적인 단어는 피하고 동사 사용 금지
동사구를 사용 save, delete 등등..
한 개념에 한 단어를 사용 같은 메소드를 클래스마다 get, fetch 등 다르게 사용 하면 헷갈린다
적절한 접두어 사용
불필요한 맥락을 제거
해법 영역 즉 silgleton 같이 친숙한 용어 사용 권장

결론 : 변수명이든, 클래스명이든, 함수명이든 이름이 중요하다

3. 함수

함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
- 함수 당 추상화 수준은 하나로, 추상화 수준이 높은 함수의 경우 다른 함수도 높은 수준의 추상화를 구현해야 한다
  ex) getHtml()은 상당히 높은 추상화 이와 같은 함수를 사용하는대 동시에 .append()와 같은 낲은 수준의 추상화를 같이 사용하지 말라.. 이러면 읽는 사람이 개념인지 세부사항을 구현한 함수인지 구분하기 어려워진다.
- 부수효과를 발생하지 말아라
위에서 아래로 -> 추상화 수준이 낮아지는 방식으로 이야기를 읽듯이 구현
모듈내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다
인수는 0개가 이상적.그 다음이 1,2, 3이상부터는 가능하면 피하는게 좋다 4는 특별한 이유 아니고선 무조건 피하기
- 인수가 많아질수록 독자가 함수 파악이 어려워진다. ex render(boolean isSuite) 보다는 renderForSuite()가 한눈에 보기 편함
인수가 많아지면, 클래스로 만드는 방법을 고려해봐라
객체 상태를 변경하거나, 객체 정보를 반환하거나 둘 중 하나이다. 둘다 사용하면 안된다.
오류코드구문 if로 구분하지말고 try-catch로 구분
반복하지 말아라.
함수는 동사, 클래스는 명사

결론 : 이유불문, 함수는 최대한 작게 만들어라, 구현이 아니라 어떻게 풀어갈지 잘 서술하는 느낌으로 설계하라

4. 주석

주석은 실패한코드, 잘 작성한 코드는 그 자체로 의도가 분명하다.
프로그램은 변화하는데 그에 맞게 주석을 관리하기란 현실적으로 불가능! 그래서 주석은 최대한 피해라.
그렇다면 좋은 주석은? 저작권라이센스, 정규식 설명, 의도 설명, TODO주석 Javadocs 등
나쁜 주석은? 의무적 주석, 이력 주석, 닫히는 구문에 주석, 기본적인 설명 주석 등

결론 : 주석은 불필요하다. 단 필요한 경우도 존재하니 필요할때만 작성

5. 형식 맞추기

적절한 행 길이를 유지하라.일반적으로 짧을수록 이해하기가 편하다.
개념은 빈 행으로 분리해라 함수와 함수, 패키지와 클래스명 등등
개념있는 관계는 세로로 밀집시켜라
연관 관계의 함수끼리는 세로거리로 연관성을 표현한다 -> protected 변수를 피해야 하는 이유중 하나.. 부모 클래스를 가봐야 하니까
변수선언은 사용하는 위치에 최대한 가까우 곳에 선언, 인스턴스는 클래스 맨 처음에
가로 정렬은 기본적으로 강조의 의미가 불분명해져서 불필요.. 멤버가 길어지면 클래스를 쪼개는것을 고려
팀 규칙이 있다면 결국 그게 규칙이다.

결론 : 형식을 맞춰서 가독성이 좋은 코드를 작성해야 한다.

객체와 자료 구조

자료구조나 알고리즘의 경우 객체보단 절차적인 클래스가 좀 더 효율적

결론 : 새로운 타입을 추가하는 유연성이 필요하면 객체로, 새로운 동작이 추가되는 유연셩이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.

오류 처리

깨긋한 코드는 읽기도 중요하지만, 안정성도 높아야 한다. 오류 처리와 프로그램 논리를 분리하면 유지보수성이 크게 높아진다.

경계

경계에 위치하는 코드는 깔끔하게 분리, 테스트 케이스를 작성해둔다. 우리쪽 에서 외부 패키지를 자세하게 알 필요가 없다. 통제 불가능한 외부 api 대신 통제 가능한 내부에 의존하는게 좋다. 외부 패키지 호출코드를 줄여 경계를 관리하자. wrapper로 감싸거나 adapter 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자.

단위 테스트

실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

테스트의 F.I.R.S.T 5가지 조건

Fast 빨라야 한다. 테스트가 느리면 테스트를 돌리기 부담스러움 -> 코드 품질 엉망으로 이어진다.
Independent 독립적이어야 한다. 각 테스트는 독립적이고 어떤 순서로 실행해도 상관 없어야 한다.
Repeatable 반복 가능하게 : QA호ㅓㅏㄴ경, 인터넷 환경에 상관없이 실행할 수 있어야 한다.
Self-Validating 자가 검증하는 : 테스트는 bool 값으로 결과를 내야한다. 성공아니면 실패
Timely 적시에 : 테스트는 적시에 작성해야한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

클래스

클래스는 작아야한다. 함수에서의 작아야 한다는 의미가 아니라 단일 책임의 원칙을 지켜야 한다.
- 얼만큼 작아야 하나? 함수는 물리적인 행 수로 크기를 측정했다면, 클래스는 맡은 책임을 센다.
- 그렇다면 단일 책임이란 무엇인가? 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다는 원칙이다.
인터페이스를 사용한 변경으로부터 격리 사용하기, 외부 API를 받아올때 바로 사용하지말고 하나의 인터페이스를 두어서 호출

창발적 설계로 깔끔한 코드를 구현

모든 테스트를 실행한다.
중복을 없앤다.
프로그래머의 의도를 표현한다.
클래스와 메서드 수를 최소로 줄인다.

위에서부터 중요도 순서

살아있는 프로그램

그저 돌아가는 코드가 아닌, 점진적으로 개선하는 코드를 작성해라. 한번에 완벽한 프로그램을 만들 필요는 없다.
점점 개선해 나가면 된다. 저자는 테스트주도 개발을 기반으로 코드를 계속 리팩토링해 나간다.

마무리

책의 마지막 부분에는 실제 사례를 통해서 위 이론들을 어떻게 풀어가는지에 대해 자세히 나와있다.
책에는 위 내용 말고도 더 자세히 많은 내용이 담겨있으니, 깨긋한 코드란 무엇인지 고민해보고 싶은 사람이라면
한번쯤 아니 두번 세번 읽어봐야할 책인 것 같다.

[독서리뷰] 객체지향의 사실과 오해 리뷰

효기로그 — Thu, 19 Mar 2020 14:08:53 +0900

이책을 처음 알게된 시점은 인프런의 김영한님의 JPA 강의를 보는데 강의 초반에 해당 책을 짧게 소개해주면서 강의를 진행했습니다. 그리고 강의를 계속 보는데 객체적인 관점?에 대해 강조를 많이 하시고, 실제 듣다 보면 나도 객체지향적인 프로그래밍 방식을 사용하고 있지 않구나라는 생각이 들어 해당 책을 구매해서 읽어 보고 독후감 같은 느낌으로 내용을 정리해봅니다.

시작하며

사실 객체 지향하면 떠오르는 추상화, 캡슐화, 상속, 다형성 4개의 단어가 떠오릅니다.
그리고 우린 이러한 객체 지향이란 특성을 이해하기 위해서 실제 세계를 기반으로 객체의 개념을 이해했습니다.
예를 들어 저는 클래스는 붕어빵틀이고 객체는 붕어빵이다 라는 문구를 통해 객체 = 클래스 라는 개념이 머리속에 자리잡혔던 것 같습니다. 이 책은 이런 저를 비웃기라도 하듯 객체란 무엇인지 부터 설명을 시작합니다.

객체지향의 목표는 실세계를 모방하는 것이 아니다, 오히려 새로운 세계를 창조하는 것이다.

객체란 실 세계를 모방하는 것이 아니다. 우리는 객체를 이해하기 위해 실세계를 모방 해왔습니다. 예를 들어 자동차 클래스를 만들고, 핸들, 기어 등을 가지며 전진, 후진 등의 기능을 가진 객체를 만들면서 객체의 속성과, 기능을 배워왔습니다. 하지만 실제로 프로그랭을 하면서 자동차, 붕어빵 등의 클래스를 만든 기억이 존재하나요? 물론 누군가는 있을수도 있지만 거의 존재하지 않습니다. 그렇다면 현실과 객체의 세계는 어떤 부분이 다를지 생각해봅니다.

객체간 메세지를 전달하며 상호 간 협력하는게 객체 지향입니다. 앞서 언급한 자동차의 경우 실 세계에선 '사람'이 '자동차'의 시동을 걸고, 주행을 할 뿐입니다. 그러나 객체 세계에서의 자동차는 스스로 시동걸기와, 주행의 기능을 가지고 있습니다. 그리고 '사람'은 '자동차'에게 요청(메세지)를 보낼 뿐입니다. 객체 세계에서의 자동차는 마치 하나의 생명체 같이 메세지를 받으면 자율적으로 메세지에 대한 처리를 합니다.

결론 : 실제는 객체와 현실은 전혀 다른 세계이기 때문에 그 차이를 인지하고 객체지향적으로 접근하는 것

그래서 객체란 무엇이고 객체 지향의 본질은 무엇인데?

이 책에서는 객체가 객체 답기 위해선 아래 3가지를 충족해야 한다고 정의합니다

객체는 협력적이어야 한다. 혼자 모든걸 해결하려 하지 말아라.
객체는 자율적이어야 한다.
데이터와 프로세서를 분리하지 않고, 둘다 스스로 가짐으로써 자율적인 존재이다.

객체는 자율적이어야 한다에 대해서 조금 더 설명을 하자면, 객체는 요청(메세지)에 따라 스스로 판단하고, 행동할 수 있어야 된다는 말입니다.

객체 지향의 본질에 대해서는 아래와 같이 정의합니다

객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법
자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.
객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
객체는 다른 객체와 협력하기 위해 메세지를 전송하고, 메세지를 수신한 객체를 메세지를 처리하는데 적합한 메서드를 자율적으로 선택한다.

여기서 1,2번은 앞서 설명한 내용과 중복이 됩니다. 그만큼 이 책에서 강조하는 부분이라 생각합니다. 추가로 눈치가 빠르신 분들은 객체라는 단어 말고 역할, 책임, 협력, 메세지,라는 단어가 계속 반복해서 나오는걸 눈치채셨을 겁니다. 이 키워드들은 앞으로 계속 강조되는 부분이니 기억해두길 바랍니다.

객체의 행동, 상태, 식별자

우리는 방금까지 객체는 어때야 하고, 객체 지향이란 어떤것인지에 대해 알아봤습니다. 이제 객체란 무엇인지 조금 더 구체적으로 설명을 합니다. 이 책인 객체를 다음과 같이 정의합니다.

객체란 식별 가능한 개체 또는 사물이다. 구체적인 사물또는 추상적인 개념일 수 있다.

이러한 객체들의 상태를 변경할 수 있는것은 오로지 객체 자신의 행동입니다. 여기서 행동에 대해서 이책은 아래와 같이 정의합니다.

행동이란 외부의 요청 또는 수신된 메세지에 응답하기 위해 동작하고 반응하는 활동. 활동의 결과로 객체는 자신의 상태를 변경하거나 객체에게 메세지를 전달할 수 있다.

마지막으로 식별자란 말 그대로 객체는 식별이 가능하다는 뜻입니다. 현실 세계이든 객체 세계이는 상태의 변화는 존재합니다. 여기서 우리가 Member member = new Member 이라고 선언 후, member.setName("Lee") 로 객체를 선언했고, 동일하게 member2 객체를 만들어준다. 이때 name이 같다고 해서 두 객체는 같은 객체라고 할 수 있는가? 당연히 아닙니다. name이 동등할 뿐이지 두 객체가 동일하지는 않다는 말입니다.

모든 것은 행동이 상태를 결정한다

위 주제가 핵심 주제라고 생각합니다. 예를 들어 우리가 Car 클래스를 하나 만든다고 생각해봅니다. 이때 우리는 어떻게 합니까? 저의 경우 아래와 같이 행동 할 것 입니다.

클래스를 하나 생성한다.
속성을 정한다. id 값을 넣고, 자동차의 모델명, 색상, 바퀴 등등등..

이 책은 이와 같은 접근 방법은 잘못되었다고 정의합니다. 우리가 만드는 협력 속에서 Car 객체는 어떤 객체와 어떤 메세지를 주고 받을지 예상을 하고 객체의 속성을 결정하는가? 즉 행동을 생각한 후 행동을 수행할 객체를 선택, 필요한 속성이 결정되어야 합니다.

협력안에서의 객체의 행동은 객체가 완수해야할 책임이라고 표현합니다. 따라서 어떤 행동 즉 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 합니다. 이에 따라 객체가 선택되고 속성이 정의되어야 합니다. 이 같은 방법을 따르면 응집도 높고 재사용이 가능한 객체를 만들 수 있게 해줍니다.

타입과 추상화

도로 위 여러 종류의 승용자, 트럭, 화물차 등이 달리고 있을 때 우리는 '차'라는 분류로 하나로 묶을 수 있다. 이와 같이 사물들의 공통접을 취하고 차이점은 버리는 일반화를 통해 단순화하는 것을 추상화라고 합니다.

객체지향에서의 추상화는 중요합니다. 이런 추상화를 통해서 나오는게 객체의 타입입니다.
그렇다면 타입을 결정짓는 요소는 무엇인가? 결국엔 여기서도 행동이다. 어떤 행동에 따라 객체들을 분류하고, 추상화해서 타입이 결정된다. 그리고 이러한 타입을 구현할 수 있는 한가지 방법이 클래스일 뿐 클래스는 객체가 아닙니다.

타입이 같은 객체끼리 같은 메세지를 수신하지만, 결과적으로 각 객체별로 내부 표현 방식이 다를 수 있기 때문에, 동일한 메세지에 대한 처리가 다릅니다. 이를 다형성이라고 말합니다.

결론 : 즉 객체의 타입이든, 속성이든 정의를 하기 위해선 객체와 객체 사이 어떤 메세지가 주고 받을지 즉 행동을 최우선으로 생각하고, 그에 따른 객체의 타입과 속성을 결정해야 합니다.

역할, 책임, 협력

역할, 책임, 협력, 메세지 키워드 중 메세지에 대한 중요성과 설명을 했고, 쉬어가는 타임으로 역할, 책임, 협력에 대해서 알아보겠습니다.

협력은 말 그대로 협력입니다. 객체는 협력속에서 책임에 따른 역할이 존재합니다.
예를 들어 어떤 사람이 자동차에 시동을 걸고 전진한다고 생각해봅니다.

이때 사람이라는 역할은 제가 될 수도, 여러분이 될 수도 자동차라는 역할은 승용차, 세단, 트럭 어떤 객체가 될 지 모릅니다. 여기서 '사람' 이라는 역할과 '자동차'라는 역할을 만들어서 협력을 구성했습니다. 이렇게 '역할'은 객체의 추상화입니다.
또한, 협력 또한 추상화할 수 있습니다. 예를 들어 제가 승용차에 시동을 건다, 제가 트럭에 시동을 건다.. 와 같은 협력을 사람이 시동을 건다. 라는 간단한 협력으로 추상화할 수 있게 해줍니다.

위 과정에서 어떤 객체가 요청에 대해 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 객체가 책임을 가진다고 말합니다.
예시에서 사람이라는 역할이 자동차라는 역할에게 시동을 걸라는 메세지를 요청합니다. 이때 자동차라는 역할은 스스로 시동을 걸고 어떠한 행동이나 응답을 해야 한다는 책임이 생깁니다.
이와 같은 과정에서 자동차마다 시동을 거는 방식이 다를겁니다. 이를 시동을 건다 라는 책임으로 인터페이스를 구성합니다.

객체지향 설계 기법

책임주도 설계
- 협력에서 책임 식별후, 적합한 객체에 책임을 할당하는 방식
- 여태 강조한 협력속에서 어떤 책임이 필요하고, 어떤 객체가 필요한지 결정하는 과정이 전체 설계 자체를 주도하는 방식
디자인 패턴
- 정해진 협력, 책임, 역할의 템플릿으로, 책임-주도 설계의 절차를 따르지 않고도, 빠르게 협력, 책임, 역할을 선택 가능
테스트 주도 개발
- 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메세지를 수신할 때 어떤 결과를 반환하고, 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 방식
- 이 과정에서, 테스트 코드는 덤이고, 리팩토링의 이점도 존재

객체를 올바르게 설계하기

깔끔한 협력을 설계
협력의 흐름에 따라 객체의 책임 설계
책임을 결정한 후에 그 행동을 수행하는데 필요한 데이터를 고민

결론 : 협력을 설계하고, 협력에서의 책임을 기준으로 전체적인 설계가 주도되어야 한다.쉽게 말해 메세지를 먼저 정하고, 해당 책임들을 역할(객체)에개 적절하게 할당하는 방식으로 설계가 주도되어야 한다.

책임과 메세지

객체 지향의 강력함을 누리기 위한 출발점은 책임을 자율적으로 만드는 것입니다. 그리고 이것은 여러분이 선택하는 메세지에 따라 달라집니다.
자율적인 객체란? 객체 스스로 판단에 따라 책임을 수행하는 것을 뜻하며, 또한 해당 책임에 따라 적절한 객체를 할당하는 과정이 객체 지향의 설계입니다. 이 때문에 책임-주도 설계 방식이 널리 사용

객체는 스스로 판단에 따라 책임을 수행해야 한다고 말했습니다. 그렇기 때문에 메세지는 너무 세세한 요구를 하면 객체의 자율성을 무너뜨립니다.
예를들어, 자동차가 시동을 걸어야 하는 책임이 있다고 가정합니다. 이때, 세세하게 스마트 키를 이용해서 시동을 걸어라, 일반 키를 이용해서 시동을 걸어라 등의 세세한 메세지는 객체의 자율성을 무너트립니다. 자율적인 객체는 스스로가 판단해서 스마트키이든, 일반 키 방식이든 선택해서 시동을 걸어야 합니다.
그렇다고 너무 추상적인 책임은 좋지 못합니다. 예를 들어 그냥 시동을 걸어라일 경우, 자동차의 시동인지 오토바이의 시동인지 알 수 없기 때문입니다. 따라서 협력 관계 속에서 절절한 수준에서 추상적으로 책임을 선택해야합니다.

인터페이스, 다형성

자동차의 시동을 걸어라라는 메세지를 수신했을 때, 스마트키 자동차와, 일반 키로 동작하는 자동차는 같은 메세지를 수신하지만 다른 행동을 합니다. 이와 같이 다형성이라는 형질을 이용해, 송신자는 수신자를 몰라도 요청이 가능하게 되면서 수신자의 외부와 내부처리를 분리하는 캡슐화도 가능합니다.

다형성의 장점

송신자는 수신자가 누구인지 상관없이 메세지만 수행하면 된다.
메세지만 변경이 없다면, 수신자를 변경하거나 수정해도 송신자에겐 영향이 없다.
협력에 영향 없이 다양한 적절한 객체들이 수신자로 대체할 수 있다.

이와 같이 송신자와 수신자를 분리할 수 있는 이유는 바로 객체들간 통신은 메세지를 통해 이루어지기 때문이다. 그래서 객체가 메세지를 선택하는게 아닌, 메세지를 중심으로 적절한 객체를 선택, 메세지를 중심으로 협력을 설계해야 합니다.

**결론 : 메세지를 기반으로 책임을 자율적으로 만들어야 한다.

기능의 관점, 구조의 관점

실세계이든 객체 세계이든 변화는 막을 수 없다. 그렇기 때문에 기능의 관점으로 설계를 할 경우, 재사용이 불가능하고 수정이 반복이 된다. 예를 들어 길을 찾아가는데 사람에게 물어가며 길을 찾아간다고 생각해보자. 누군가가 앞으로 가시다가 사거리에서 우회전... 편의점에서 좌회전...등등 직관적이고 해결이 쉽겠지만, 3년후 같은 같은 위치에서 같은 질문을 했을 경우 해당 위치에 편의점이 없어질수도, 극단적으로 사거리가 없어질수도 있다. 아무도 예측이 불가능합니다.
그렇다면 지도를 보고 찾아가는 구조의 관점으로 접근해보자. 전체적인 지형의 형태로 길을 찾아가기 때문에 해당 건물에 편의점이 음식점으로 바뀌어도 원하는 길을 찾아가는데 문제가 없습니다.

기능 설계 vs 구조 설계

그렇다면 기능은 필요가 없는가? 전혀 아니다. 기능은 즉 서비스입니다. 설계 초반에 사용자가 원하는 요구를 파악하고, 충족하기 위해 어떤 기능을 제공해야 하는지 초점을 맞춰야 합니다.
구조는 기능을 구현하기 위한 기반으로, 변경을 수용할 수 있도록 안정적이어야 합니다.

기능과 구조를 표현하기 위한 기법

기능 표현 : 유스케이스 모델링
구조 표현 : 도메인 모델링

유스케이스 모델을 통한 기능과, 도메인 모델을 통한 구조를 책임-주도 설계로 합쳐서 안정적인 시스템을 만드는 방법을 연습해야 한다.
또한 코드 작성은 도메인 모델을 기반으로 작성해 방향성을 잃지 않고 코드를 작성하도록 한다.

결론 : 요구사항을 식별, 도메인 모델을 생성한 후, 코드를 작성 후, 요구사항을 충족시키기 위해 객체들간의 메세지 전송을 정의해야 한다.

마무리

책에 대한 전반적인 리뷰를 마무리하며, 해당 책에는 이상한 나라의 엘리스라는 책을 기준으로 더 많은 내용과 설명을 몰입도 있게 표현하고 있으니, 조금이라도 객체지향에 대한 호기심이 생긴 사람이라면 적극적으로 읽어볼 것을 추천합니다. 또한 책의 분량도 많지 않기 때문에 부담 없이 읽으면서 조금 더 견문??이 넓어지는 듯한 생각이듭니다. 책을 적극적으로 추천합니다.

결론 모아보기

실제는 객체와 현실은 전혀 다른 세계이기 때문에 그 차이를 인지하고 객체지향적으로 접근하는 것
객체의 타입이든, 속성이든 정의를 하기 위해선 객체와 객체 사이 어떤 메세지가 주고 받을지 즉 행동을 최우선으로 생각하고, 그에 따른 객체의 타입과 속성을 결정해야 한다.
협력을 설계하고, 협력에서의 책임을 기준으로 전체적인 설계가 주도되어야 한다.쉽게 말해 메세지를 먼저 정하고, 해당 책임들을 역할(객체)에개 적절하게 할당하는 방식으로 설계가 주도되어야 한다.
메세지를 기반으로 책임을 자율적으로 만들어야 한다.
요구사항을 식별, 도메인 모델을 생성한 후, 코드를 작성, 요구사항을 충족시키기 위해 객체들간의 메세지 전송을 정의해야 한다.

[인강리뷰] 자바 : 클래스의 이해와 객체지향 프로그래밍

효기로그 — Thu, 12 Mar 2020 13:29:10 +0900

요즘 인프런을 통한 강의로 부족한 기본기를 다지는 중인데 인프런에 등록된 로드맵중 시작단계에 해당 강의가 있어서 구매하게 되었다.

이런 걸 배울 수 있어요

그동안 이해 안 되었던 책들의 내용이 이해되기 시작합니다.
자바의 고급스런 기법들에 대한 이해와 접근이 쉬워집니다.
프로그래밍시 클래스의 활용이 좀 더 쉬워집니다.
좀 더 객체지향적인 프로그래밍을 할 수 있습니다.

클래스를 알면 자바가 정말 쉽습니다.

자바는 클래스로 시작해서 클래스로 끝난다고 볼 수 있는데
그렇다면 클래스를 안다는 것이 얼마나 중요한 일이겠습니까?

이 강의를 통해 클래스를 이해하고 많은 용어를 이해하면
자바 코드를 볼 때 "아 이게 그거였구나"하면서
자바 코드를 보는 것이 즐겁게까지 느껴질지도 모릅니다.( 바램입니다 ^^ )

...이하 생략

수강 대상

자바 책을 한 번이라도 훌어보신 분
클래스가 잘 이해가 안 되고 활용도 안 되는 분
자바 프로그래밍을 잘 하고 싶으신 분
초급과정입니다.

느낀점

우선 인프런에서 로드맵을 통해 공부중에 해당 강의는 기본 강의라고 생각해서 패스했었습니다.
그런데 요즘 코로나 관련해서 강의가 세일중이기에... 부담스럽지 않은 가격이라 구매를 결정 후 하루만에 정독하였습니다.
우선 수강 대상이 자바 프로그래밍을 잘 하고 싶으신 분 이라는 문구가 제일 눈에 띄여서 구매를 결정했던거 같습니다.
내용은 일반 책이나 강의에서 들을 수 없는 부분까지 설명을 해주시고 왜 사용하는지, 이론부터 설명을 해주기 때문에 자바를 처음 공부하는 사람은 자바 책과 같이 들으면 좀 더 이해가 쉬웠을거 같다고 생각합니다.
사실 저의 경우도 취업전까지 추상클래스나, 인터페이스, 다형성 등등등 자세히 모르고 그냥 사용하다가 면접을 준비하면서 공부한 케이스인데 해당 강의를 보면 이런 부분에 대한 설명이 쉽게 나와있습니다.
여기서 젤 중요한 부분은 자바를 처음 접하고 기본서를 공부중이신 분들에게는 강추하는 강의입니다.
그러나 기본서는 필요없다 하는 분들은 말 그대로 초급과정의 강의이기 때문에 불필요하다고 생각합니다.

[독서리뷰] 코드로 배우는 스프링 웹 프로젝트 - 개정판

효기로그 — Mon, 9 Mar 2020 10:15:27 +0900

스프링 공부를 하고 싶어서 여러 블로그, 커뮤니티 등을 참고해서 책을 선정하기로 마음 먹었다. 사실 맨 처음 사람들이 추천해주는 토비의 책으로 공부하려고 했으나.. 우선 책의 두께가 있어서 그런지 책을 보기도 전에 덜컥 거부감과 부담이 생겨서 좀 더 이론보다는 구현을 해보자라는 마음에 해당 책을 선택했습니다. 우선 내용은 신입??이 스프링기반 웹 프로젝트를 기본은 할 수 있도록 가이드를 제공해주는 책이라고 생각하면 됩니다.

책 소개

이 책은 Spring Framework를 사용해서 웹 프로젝트를 어떻게 생성하고, 진행하는지 설명하는 책입니다.
좀 더 구체적으로는 스프링으로 웹 프로젝트에서 사용되는 게시물 관리를 만들어 보는 것이 주된 목적입니다. 모든 웹 프로젝트는 그 성격에 따라 구성과 구조가 다르기는 하지만 결과적으로는 게시물 관리 모듈의 집합체라고 볼 수 있습니다. 이 책에서는 웹 프로젝트에 사용되는 게시물을 다음과 같은 예제들로 작성합니다.

저자 소개 - 구멍가게 코딩단

프로그래밍을 좋아하지만. 남들 앞에 나설 용기 없는 10년 차 이상 개발자, 현업 관리자, 강사들의 비공개 모임.
어린 시절 구멍가게 앞 아저씨들이 인생의 진리를 가볍게 던졌던 것처럼 프로그래밍의 오의를 가볍게 던지고 싶은 사람들의 모임

느낀점

우선 읽은 사람들 모두, 예제에 나온 오타, 맞춤법 등의 악평이 많지만... 뭐 저는 읽으면서 불편하다고 느끼지는 않았습니다.
또한 스프링 프레임워크에 대한 이론적인 부분 보다는 예제를 통한 프로젝트를 구현하는게 목표인 책이다 보니, 책을 읽어가면서 부족한 부분은 Spring Docs나 다른 블로그 등을 참고해서 이론부분을 채워가면서 읽으니까 좀 더 스프링에 대해서 이해하는데 도움이 된 것 같습니다. 전체적으로 스프링에 대해서 처음 입문하고, 스프링 하면 덜컥 겁부터 나는 저같은 사람에겐 소중한 책이였던것 같습니다.
스프링을 공부해야 하는데 책이 어렵고, 뭐부터 해야 할지 모르겠는 사람에게 추천하는 책입니다.

[Spring] Spring Project 생성, xml 없이 java로 설정하기 (web.xml servlet-context.xml root-context.xml 제거 )

효기로그 — Sun, 1 Mar 2020 02:02:50 +0900

해당 내용은 코드로 배우는 스프링 웹 프로젝트 라는 책의 내용을 기반으로 작성된 내용입니다.

Spring 프로젝트 생성

시작은 'Spring Legacy Project'로 프로젝트를 하나 생성해줍니다.
그럼 아래 그림과 같이 프로젝트 구조가 생성되는데, 이중 .xml로 설정된 파일을 제거하기 위해
web.xml을 삭제하고 servlet-context.xml과 root-context.xml을 포함하고 있는 spring 폴더 자체를 삭제해줍니다.

삭제 후 pom.xml에 에러 표시가 발생합니다. 이는 기존 웹 프로젝트들이 web.xml을 사용하는 것을 기반으로 설정했기 때문입니다. 에러를 제거하기 위해 pom.xml의 의 아래와 같은 설정을 추가

<plugins>
  <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <version>3.2.3</version>
        <configuration>
          <failOnMissingWebXml>false</failOnMissingWebXml>
      </configuration>
  </plugin>
...
<plugins>

마지막으로 pom.xml에 java 관련 버전 설정을 1.7로 되어있는 데 사용하는 버전으로 변경 ( properties 와 maven-compiler-plugin ) 설정을 마무리하고 프로젝트 우클릭 -> maven -> update project 실행

위 과정을 마치면 일단 오류는 사라집니다. 이제 남은 과정은 삭제한 xml파일의 설정 값들을 java Class로 추가하는 작업입니다.

root-context.xml 대체하기

root-context.xml 이란 ?
Spring는 Context라는 영역을 만들어서 거기서 bean들을 관리해주며, 여러 개의 Context를 가질 수 있고 servlet-context 다음 root-context라는 계층형 구조를 가지고 있습니다. 이중 root-context 영역에 대한 설정을 담당하는 파일이 root-context.xml 입니다.

또한 계층 구조상 root-context는 servlet-context 인스턴스에서 공유해야 하는 데이터 저장소 및 비지니스 서비스와 같은 인프라 Bean을 등록하게 됩니다. 쉽게 말해 datasources와 같이 공통 사용 빈 또는 설정할 때 사용하게 됩니다. 참조

그럼 서론은 여기까지 하고, 아래와 같이 적당한 패키지와 클래스 이름을 정해서 클래스를 하나 정의해줍니다.

package config;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan(basePackages = {"com.ljh.study"})
public class RootConfig { }

@Configuration 어노테이션은 해당 클래스를 설정 클래스라고 알려주는 어노테이션입니다.
@ComponentScan 어노테이션은 기존 xml에 사용하던 것과 동일하게 @Componet로 선언된 클래스들을 Bean으로 인식해 Context 영역에 객체를 생성하도록 해주는 어노테이션 설정입니다.

RootConfig Test 작성

방금 만들어진 RootConfig 클래스가 정상적으로 동작하는지 테스트하기 위해 하나의 클래스를 만들어줍니다.

package com.ljh.study.sample;
import org.springframework.stereotype.Component;

@Component
public class Sample { }

@Component라는 어노테이션을 통해 Spring Context가 관리해야 되는 객체라고 선언합니다.
여기까지 완료되었으면, 이제 테스트 코드를 작성합니다. 테스트는 원하는 버전을 선택합니다. 저의 경우 Junit5를 사용하였습니다.

@DisplayName("Root Context 테스트")
@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = RootConfig.class)
public class RootConfigTest {

    private Sample sample;

    @Autowired
    public RootConfigTest(Sample sample) {
        this.sample = sample;
    }

    @Test
    @DisplayName("Root Context Component scan 확인")
    void rootContextComponentScanTest() {
        assertNotNull(sample);
    }
}

RootConfig 클래스를 통해 정상적으로 Bean들이 등록이 되었다면 @Autowired가 동작을 하고 객체에 의존성을 주입받을 것입니다.
실행을 하면 아래와 같이 테스트가 통과하는 걸 확인할 수 있습니다.

web.xml 대체하기

이제 web.xml을 대신할 클래스를 아래와 같이 작성합니다.

package config;
import org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer;

public class WebConfig extends AbstractAnnotationConfigDispatcherServletInitializer{

    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class[] {RootConfig.class};
    }

    @Override
    protected Class<?>[] getServletConfigClasses() {
        return null;
    }

    @Override
    protected String[] getServletMappings() {
        return null;
    }
}

WebApplicationInitializer를 상속받아 구현하는 방법도 존재하지만 해당 클래스의 구현체인 AbstractAnnotationConfigDispatcherServletInitializer를 상속받아 좀 더 간편하게 구현이 가능합니다.

이제 Run As -> Run On Server로 실제 동작을 해보면 콘솔에 아래와 같은 로그가 찍히면서 WebConfig 클래스의 설정이 적용이 되었는지 확인할 수 있습니다.

INFO : org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization started
INFO : org.springframework.web.context.ContextLoader - Root WebApplicationContext initialized in 531 ms
INFO : org.springframework.web.servlet.DispatcherServlet - Initializing Servlet 'dispatcher'
INFO : org.springframework.web.servlet.DispatcherServlet - Completed initialization in 219 ms

만약 해당 로그가 뜨지 않는다면 정상적으로 설정이 되지 않은 것이니 다시 확인하셔야 합니다.

DB 연결하기

해당 예제에서는 DB로 Oracle 11g를 사용합니다.
오라클 버전에 맞는 JDBC 스펙을 Oracle 홈페이지에서 확인 후 프로젝트에 추가 해줍니다.

위와 같이 사전 준비가 완료되었다면, 이제 DB에 정상적으로 접속이 되는지 테스트 코드를 작성해봅니다.

@Log4j
@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = RootConfig.class)
@DisplayName("DB 관련 테스트")
public class DBTest {

    @Test
    @DisplayName("JDBC 연결 테스트")
    void jdbcTest() {
        try {
            DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
            try (Connection connection = 
                    DriverManager.getConnection(
                              "jdbc:oracle:thin:@localhost:1521:orcl"
                            , "study"
                            , "study")) {
                log.info(connection);
            }
        } catch (SQLException e) {
            log.error(e.getMessage());
        }
    }

위와 같이 각각 DB에 맞는 드라이버를 등록 후 접속을 테스트 해보는 간단한 테스트입니다.
정상적으로 동작한다면 Log4j를 통해 출력된 connection 객체의 정보가 출력될 것 입니다.

Connection Pool 사용

이제 DB랑 접속이 되는지 확인이 되었으니, 커넥션 풀을 설정할 차례입니다. 예제에서는 HikariCP를 사용합니다.
우선 HikaraCP를 사용하기 위해 pom.xml에 아래와 같이 의존성을 추가해줍니다.

<!-- https://mvnrepository.com/artifact/com.zaxxer/HikariCP -->
<dependency>
      <groupId>com.zaxxer</groupId>
      <artifactId>HikariCP</artifactId>
      <version>3.4.2</version>
</dependency>

그 후 기존에 작성된 RootConfig클래스에 다음과 같이 Bean을 추가해줍니다.

@Configuration
@ComponentScan(basePackages = {"com.ljh.study"})
public class RootConfig { 

    @Bean
    public DataSource dataSource() {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setDriverClassName("oracle.jdbc.OracleDriver");
        hikariConfig.setJdbcUrl("jdbc:oracle:thin:@localhost:1521:orcl");
        hikariConfig.setUsername("study");
        hikariConfig.setPassword("study");

        return new HikariDataSource(hikariConfig);
    }
}

위와 같이 root-context를 수정해서 DataSource를 HikariDataSource로 설정해줍니다.
이런 설정을 통해 dataSource라는 빈에 hikariConfig를 참조시키는 설정을 진행하게 됩니다.

자 이제 당연하게 HikariCP가 정상적으로 적용이 되었는지 Test를 작성해줍니다.

@Log4j
@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = RootConfig.class)
@DisplayName("DB 관련 테스트")
public class DBTest {

    private DataSource dataSource;

    @Autowired
    public DBTest(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Test
    @DisplayName("Hikari 설정 테스트")
    void datasourceTest() {
        try(Connection connection = dataSource.getConnection()){
            log.info(connection);
        } catch (Exception e) {
            log.error(e.getMessage());
        }
    }
}

간단하게 위와 같이 테스트 코드를 작성하고 실행해보면 Test코드가 실행하면서 Spring가 Bean으로 HikariCP를 통해 커넥션을 사용하는 로그가 찍히는지 확인해봅니다.

INFO : com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Starting...
INFO : com.zaxxer.hikari.pool.PoolBase - HikariPool-1 - Driver does not support get/set network timeout for connections. (oracle.jdbc.driver.T4CConnection.getNetworkTimeout()I)
INFO : com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Start completed.
....

Mybatis 연동

Mybatis를 사용하기 위해 아래의 의존성들을 추가해줍니다.

<!-- https://mvnrepository.com/artifact/org.mybatis/mybatis -->
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.4</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.mybatis/mybatis-spring -->
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis-spring</artifactId>
    <version>2.0.3</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.springframework/spring-jdbc -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>${org.springframework-version}</version>
</dependency>

추가로 spring-tx가 없으신분들은 추가로 의존성을 작성해줍니다.

이제 사용하기 위한 사전 준비는 끝났고, Mybatis에서 사용하는 클래스들중 SQLSession과 SQLSessionFactory를 사용하기 위해 스프링에 Bean으로 등록해주는 작업을 해줍니다.
기존에 작성된 RootConfig클래스에 아래와 같이 Bean을 추가로 작성해줍니다.

@Bean
public SqlSessionFactory sessionFactory() throws Exception {
    SqlSessionFactoryBean sessionFactoryBean = new SqlSessionFactoryBean();
    sessionFactoryBean.setDataSource(dataSource());
    return sessionFactoryBean.getObject();
}

두 객체에 대해서 간략하게 설명하자면 SQLSessionFactory는 이름처럼 SQLSession 객체를 생성해주는 역할을 하는 객체입니다.
SQLSession은 해당 객체를 통해 Connection을 생성하거나 원하는 SQL문을 전달하고, 결과를 리턴 받는 역할을 합니다.

이제 해당 Bean이 정상적으로 Spring에 등록이 되었는지 테스트해보는 테스트 코드를 작성합니다. 기존에 작성된 DBTest 클래스에 추가로 아래와 같이 작성을 해줍니다.

@Test
@DisplayName("myBatis 연결 테스트")
void myBatisTest() {
    try(SqlSession session = sqlSessionFactory.openSession();
        Connection connection = session.getConnection();){
        log.info(session);
        log.info(connection);
    } catch (SQLException e) {
        log.error(e.getMessage());
    }
}

실행 후 아래와 같은 결과가 나오는지 확인해봅니다.

INFO : config.DataSourceTest - org.apache.ibatis.session.defaults.DefaultSqlSession@5a9d6f02 INFO : config.DataSourceTest - HikariProxyConnection@1839168128 wrapping oracle.jdbc.driver.T4CConnection@376a0d86

여기까지 동작이 완료되었다면, Mybatis까지 연동이 성공했습니다. 이제 실제 소스에 어떻게 사용하는지 사용방법에 대해서 소개를 하겠습니다.

스프링과 Mybatis 연동처리

스프링과 Mybatis에서 SQL문을 작성할 때 Mapper을 사용합니다. Mapper은 xml로 작성할 수도, 어노테이션으로 사용할 수 도 있습니다. 예제에선 두가지 방법 모두 사용해보겠습니다.

우선 기본 구조는 Controller -> Service -> Mapper 인데 예제에선 Controller과 Service를 패스하고 바로 Mapper만 작성해보겠습니다.
Mapper은 클래스가 아닌 인터페이스로 아래와 같이 생성해줍니다.

package com.ljh.study.mapper;
import org.apache.ibatis.annotations.Select;

public interface TimeMapper {

    @Select("select sysdate from dual")
    public String getTime();

    public String getTimeForMapperXml();
}

우선 @Select어노테이션을 사용한 메소드가 어노테이션을 이용한 쿼리 작성방법이고, 아래 getTimeForMapperXml() 메소드가 xml을 이용한 방식입니다. 해당 방식은 메소드의 이름과, 리턴타입을 선언해주면 해당 Mapper 인터페이스에서 작성은 끝입니다.

여기까지가 Mapper 인터페이스 작성이였고, 기존의 Spring가 Component를 인식하기 위해 ComponentScan을 사용했던것과 비슷하게 Mybatis도 MapperScan을 제공해준다. 그러면 Mybatis와 관련된 어노테이션들(@Select 등)을 인식하고 등록하게 됩니다.
작성은 기존에 작성한 RootConfig 클래스에 어노테이션을 추가해줍니다.

@Configuration
@ComponentScan(basePackages = {"com.ljh.study"})
@MapperScan(basePackages = {"com.ljh.study.mapper"})
public class RootConfig { 
    ....
}

이제 Mapper 인터페이스 + xml을 같이 사용 하는 방법은 src/main/resources 아래 적당하게 패키지를 구성해주고 패키지 안에 TimeMapper.xml을 생성해주고 아래와 같이 작성해줍니다.

<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="com.ljh.study.mapper.TimeMapper">
    <select id="getTimeForMapperXml" resultType="String">
        select sysdate from dual
    </select>
</mapper>

여기서 중요한 점은 우리가 생성한 Mapper 인터페이스를 namespace에 연결을 해줍니다. 그리고 우리는 셀렉트문을 사용하기 때문에 select id을 통해 해당 메소드와 연결을 시켜줍니다. 또한 파라미터를 받을 수도, 결과를 리스트로 반환할 수도 여러가지 방법이 존재하니 해당 방법에 대해서 모르신다면, 따로 검색을 해보시는걸 추천합니다.

이제 다왔습니다. 해당 Mapper가 적상적으로 동작하는지 테스트를 아래와 같이 작성해줍니다.

@DisplayName("Mapper 관련 테스트")
@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = RootConfig.class)
@Log4j
public class TimeMapperTest {

    private TimeMapper timeMapper;

    @Autowired
    public TimeMapperTest(TimeMapper timeMapper) {
        this.timeMapper = timeMapper;
    }

    @Test
    public void testGetTIme() {
        log.info(timeMapper.getTime());
    }

    @Test
    public void getTimeForMapperXmlTest() {
        log.info(timeMapper.getTimeForMapperXml());
    }
}

해당 테스트를 실행 후, log가 정상적으로 출력이 되면, 이제 기본 프로젝트 생성과 Mybatis 3를 통한 DB 접속 연결까지 완료가 되었습니다.

[Spring/Core] DI(의존성 주입)은 생성자 주입을 사용해라

효기로그 — Fri, 28 Feb 2020 14:38:02 +0900

이번 내용은 스터디를 진행하는 도중에 누군가가 요즘은 필드 주입을 사용하지 않는데 왜 사용했느냐라는 질문에 대한 내용을 정리하기 위해 스프링 공식 사이트의 Spring Core의 내용을 참고해서 정리한 내용입니다.

사용 이유

아래는 Spring Document에 나와있는 원문입니다.

Constructor-based or setter-based DI?
Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies. Note that use of the @Required annotation on a setter method can be used to make the property be a required dependency; however, constructor injection with programmatic validation of arguments is preferable.

The Spring team generally advocates constructor injection, as it lets you implement application components as immutable objects and ensures that required dependencies are not null. Furthermore, constructor-injected components are always returned to the client (calling) code in a fully initialized state. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.

Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later. Management through JMX MBeans is therefore a compelling use case for setter injection.

Use the DI style that makes the most sense for a particular class. Sometimes, when dealing with third-party classes for which you do not have the source, the choice is made for you. For example, if a third-party class does not expose any setter methods, then constructor injection may be the only available form of DI.

뭐 사실 저 원문을 보려고 오신 건 아닐 거라 믿기 때문에 포스팅이 길어질걸 대비해 옆으로 길게 내용을 작성합니다.
해당 내용을 간략하게 줄여보자면, 우선 필드 주입은 언급도 안 하고, ( 여태 사용하던 나는 무엇...)
Construcor Base Injection(생성자 기반 주입)과 Setter Base Injection(수정자를 통한 주입)의 차이점에 대해서 설명합니다. 여담으로 스프링 진영도 생성자 기반 주입을 옹호한다고 나와있네요.

둘의 차이점

생성자 주입은 필수 종속성, 수정자는 선택적 종속성에 사용하라
생성자 주입은 final 키워드를 사용할 수 있다.
생성자 주입은 생성자 인수가 많아지면. 코드가 더러워 보이므로 리팩토링을 하게 된다. 라는 식으로 적혀 있는데 구글 번역기를 돌리는 거라 대충 느낌만 적었습니다.

종속성

말 그대로 객체가 다른 객체에 종속되어 있다는 말입니다. 간단한 예제를 보면

class Book{    
    JavaBook javaBook = new JavaBook();

    ...
}

class JavaBook{
    ...
}

위와 같은 구성일 때 JavaBook 클래스는 Book 클래스가 변경이 되어도 영향이 없다.
하지만 Book 클래스는 JavaBook 클래스가 변경되면 영향을 받게 된다 이러한 상태를 Book가 JavaBook에 종속되었다고 표현합니다.

간단하게 종속성에 대해서 알아봤고, 그럼 생성자 주입은 필수 종속성, 수정자 주입은 선택적 종속성에 사용하라는 게 무슨 말일까?
아래 코드를 예제로 보겠습니다. 해당 코드는 스프링 동작이 아닌 순수 자바 코드입니다.

Constructor Base

public class Controller {

    private Service service;

    public Controller(Service service) {
        this.service = service;
    }
}

public class Service { }

public class Main {
    public static void main(String[] args) {

        Controller controller = new Controller(new Service());
        Controller controller2 = new Controller(null);
    }
}

보시는 바와 같이 생성자를 통한 주입의 경우 해당 의존 객체를 필수로 주입해주지 않는 한 객체를 생성할 수 없게 됩니다.
즉, null을 직접적으로 주입하지 않는한 객체는 NullPointerException을 발생하지 않습니다. 추가로 의존 객체에 final 키워드를 사용할 수 있는 장점도 있습니다.

Setter Base

public class Controller {

    private Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void servicePrint(){
        service.print();
    }
}

public class Service { 
    public void print(){
        System.out.println("someting to do...");
    }
}

public class Main {
    public static void main(String[] args) {

        Controller controller = new Controller();
        controller.setService(new Service());
        controller.servicePrint();

        Controller controller2 = new Controller();
        controller2.servicePrint(); // NullPointerException
    }
}

반면 Setter 주입의 경우 객체 생성 시 의존관계를 주입해주지 않아도 객체 생성이 가능하게 됩니다.
그렇기 때문에 사용 시 NullPointerException이 발생할 수 있어 항상 객체의 참조가 null인지 확인해야 하는 로직이 추가로 필요하게 됩니다.

순환참조

간단하게 생성자 기반 주입과, 수정자 기반 주입에 대해서 알아봤습니다. 이제 마지막으로 순환 참조에 대한 내용입니다.
생성자를 통한 주입의 경우 순환 참조를 앱 구동 단계에서 스프링이 오류를 찾을 수 있고, 수정자 주입의 경우 런타임시, 해당 순환 참조가 되어있는 메소드를 호출하기 전까지 순환참조인지 알 수 있는 방법이 없습니다. 아래 예제를 보겠습니다.

@Service
@AllArgsConstructor
public class TestService1 {

    private TestService2 testService2; 
}

@Service
@AllArgsConstructor
public class TestService2 {
    private TestService1 testService1;
}

위와 같이 간단하게 생성자 기반 주입으로 서로 순환참조를 하도록 설정하고 스프링을 실행하면 아래와 같은 오류가 발생합니다.
Error creating bean with name 'testService1': Requested bean is currently in creation: Is there an unresolvable circular reference?

그러나 수정자의 경우 빈 생성 자체는 문제없이 됩니다.
위에서 설명한 바와 같이 서로 메소드가 순환을 참조하고 있든 아니든, 객체 생성 시엔 알 수 있는 방법이 없기 때문에 정상적으로 동작되는 것처럼 보이다 런타임 시에 오류가 발생하는 문제점이 있습니다.

정리

이렇게 스프링에서 의존성을 주입받는 방법 2가지를 비교해봤습니다. 내용을 간단하게 정리하면 아래와 같습니다.

생성자 기반 주입의 경우 NullPointException을 방지할 수 있다.
생성자 기반 주입의 경우 객체에 final 키워드를 사용할 수 있다.
생성자 기반 주입의 경우 순환 참조를 앱 구동 시 검출할 수 있다.
생성자 기반 주입의 경우 생성자의 인자가 많아지면 코드가 더러워져 리펙토링을 하게 된다.

위 4개의 장점이 Spring에 소개된 생성자 기반 주입의 장점입니다.
이렇게 장점이 많으니 앞으로 생성자 기반 주입만 사용해야겠습니다. 더불어 요즘은 lombok랑 연동해서 사용하면 어노 테이션 하나로 필드 주입과 비슷하게 작성이 가능하니 사용도 수정자 기반 주입보다 편리한 것 같습니다.

[TDD/테스트주도개발] JUnit5

효기로그 — Thu, 30 Jan 2020 10:11:56 +0900

시작하며

해당 내용은 JUnit 5 User Guide와 인프런의 더 자바, 애플리케이션을 테스트하는 다양한 방법을 정리한 내용입니다. 잘못된 부분은 댓글로 피드백 부탁드립니다.

Junit5 User Guide : https://junit.org/junit5/docs/current/user-guide/
인프런 : https://www.inflearn.com/course/the-java-application-test/dashboard

개요

이전 버전의 JUnit와는 다르게 JUnit5 부터는 모듈의 집합으로 구성되어 있음, 또한 JUnit5는 java8 이상의 버전을 필요로하나, 그 하위 버전도 JDK로 컴파일된 코드는 계속 테스트 가능
JUnit 5 = Junit Platform + Junit Jupiter + JUnit Vintage

Junit Platform
- TestEngine API를 제공해주며, 콘솔 실행 런처를 제공해줍니다.
JUnit Jupiter
- TestEngine API 구현체로 JUnit5 API를 제공
JUnit Vintage
- 하위 버전과 호환을 위해 JUnit3, JUnit4 기반의 테스트 엔진을 제공

어노테이션

JUnit5 어노테이션	내용	JUnit4 어노테이션
@Test	테스트 Method임을 선언	@Test
@ParameterizedTest	매개변수를 받는 테스트를 작성할 수 있다.
@RepeatedTest	반복되는 테스트 작성 가능
@TestFactory	@Test로 선언된 정적 테스트가 아닌 동적으로 테스트를 사용
@TestInstance	테스트 클래스의 생명주기를 설정
@TestTemplate	공급자에 의해 여러 번 호출될 수 있도록 설계된 테스트 케이스 템플릿임을 나타낸다.
@TestMethodOrder	테스트 메소드 실행 순서를 구성하는데 사용
@DisplayName	테스트 클래스 또는 메소드의 사용자 정의 이름을 선언할 때 사용
@DisplayNameGeneration	이름 생성기를 선언, 예를 들어 '_'를 공백 문자로 치환해주는 생성기가 있다. ex ) new_test -> new test
@BeforeEach	모든 테스트 실행 전에 실행할 테스트에 사용	@Before
@AfterEach	모든 테스트 실행 후에 실행한 테스트에사용	@After
@BeforeAll	현재 클래스를 실행하기 전 제일 먼저 실행할 테스트 작성 static로 선언	@BeforeClass
@AfterAll	현재 클래스 종료 후 해당 테스트를 실행 static로 선언	@AfterClass
@Nested	클래스를 정적이 아닌 중첩 테스트 클래스임을 나타냅니다.
@Tag	클래스또는 메소드 레벨에서 태그를 선언할 때 사용, 이를 메이븐을 사용할 경우 설정에서 테스트를 태그를 인식해 포함하거나 제외시킬 수 있다
@Disabled	이 클래스나 테스트를 사용하지 않음을 표시	@Ignore
@Timeout	테스트 실행 시간을 선언 후 초과되면 실패하도록 설정
@ExtendWith	확장을 선언적으로 등록할 때 사용
@RegisterExtension	필드를 통해 프로그래밍 방식으로 확장을 등록할 때 사용
@TempDir	필드 주입 또는 매개변수 주입을 통해 임시 디렉토리를 제공하는데 사용

각각 어노테이션의 사용법은 추후 시간이 나면 포스팅하고, 참고할 만한 링크를 남깁니다. 위에 링크로 연결된 JUnit5 User Guide 또는 아래 링크에서 사용법 설명을 볼 수 있습니다.
baeldung : https://www.baeldung.com/?s=Guide+JUnit5

사용자 정의 어노테이션

JUnit Jupiter의 주석은 메타 주석 으로 사용할 수 있습니다.
예를 들어 @Tag("fast")를 매번 사용하는 대신 @FAST로 정의하여 사용 가능

Fast Annotation

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Tag("fast")
public @interface Fast { }

Test Method

@Fast
@Test
void myFastTest() { 
...
}

나아가 @Fast, @Test를 섞은 @FastTest로도 선언가능

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Tag("fast")
@Test
public @interface FastTest {
}

테스트 클래스 및 메소드 작성

Test Class : 최소한 하나의 테스트 메소드를 포함하는 최상위 클래스를 말하며, abstract이면 안되고, single constructor이어야 한다.
Test Method : @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, @TestTemplate로 선언된 테스트 메소드
Lifecycle Method : @BeforeAll, @AfterAll, @BeforeEach, @AfterEach 로 선언된 메소드

작성 예시

class MyTest{

@BeforeAll
static void initAll(){ }

@BeforeEach
void init(){ }

@Test
void standardTest() { }

@Test
@Disabled("description 작성, 데모용 테스트")
void disabledTest(){ }

@Test
void abortedTest() {
   assumeTrue("abc".contains("Z"));
   fail("test should have been aborted");
}

@AfterEach
void tearDown() { } 

@AfterAll
static void testDownAll() { }
}

위와 같이 간단하게 테스트를 작성했다고 가정하면 실행 순서는
initAll() -> init() -> standardTest() -> tearDown() -> init() -> abortedTest() -> tearDown() -> testDownAll() 순으로 동작하게 된다.

JUnit5 Assertions

기본적으로 JUnit4의 Assertions를 포함하며 java 8 람다와 함께 사용하기 위해 몇가지를 추가했습니다. 모든 JUnit Jupiter 어셜션은 클래스의 static 메소드입니다. org.junit.jupiter.api.Assertions

메소드	설명
assertAll ( executables...)	구문 오류시 예외를 발생시키지 않으면서 한번에 모든 구문을 확인 할 수 있습니다.
assertEquals( expected, actual )	실제 값과 예상 값이 같은지 확인, 이 외 assertArrayEquals(), assertNotEquals() 도 존재
assertNotNull( actual )	값이 null인지 아닌지 확인
assertTrue( boolean )	다음 조건이 참인지 확인
assertThrows( expectedType, executable )	예외를 발생 시키는지 확인
assertTimeout ( timeout, executable )	특정 시간안에 실행하는지 확인
assertTimeoutPreemptively( timeout, executable )	특정 시간안에 실행하는지 확인 후, 시간을 초과하면 실행 파일의 실행이 중단되도록 설정. 단, executable와 다른 스레드에서 실행하기 때문에, 원치 않는 결과가 발생할 수 있다. ex ) 트랜잭션이 적용이 안되서 롤백이 안되는 경우

이 외 assertSame()등, 많은 메소드가 존재하니 자세한 내용은 아래 API 링크를 통해 참고하시면 될 것 같습니다.

JUnit5 Assertions API : https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/Assertions.html

그 외 써드파티 라이브러리로 AssertJ, Hamcrest, Truth등을 사용할 수 있습니다.

작성 예시

객체 생성 테스트
```
@Test
void create_new_member{
  Member member = Member.builder()
                  .name("Lee")
                  .build();
  assertNotNull(member);
  assertEquals("Lee", member.getName());
}
```
위와 같이 객체 생성이 정상적으로 되었는지, 값이 원하는 값인지 확인하는 테스트를 작성할 수 있습니다.
또한 assert에는 마지막 인자로 String 또는 Supplier<String>를 통해 메세지를 출력할 수 있습니다.

테스트 결과 오류메세지 설정

@Test
void create_new_member{
  Member member = Member.builder()
                  .name("Lee")
                  .build();
  // assertEquals("Park", member.getName(), "생성된 member의 name이 Lee가 아닙니다.");
  assertEquals("Park", member.getName(), () -> "생성된 member의 name이 Lee가 아닙니다.");
}

Exception 확인
Member에 age라는 필드를 추가해주고 생성자를 통해 생성 시 음수가 들어오면 Exception을 발생하도록 로직을 만들어 줍니다.

public Class Member {
  private int age;

  public Member(int age) {
      if( age < 0 ) throw new IllegalArgumentException();
      this.age = age;
  }
}

위와 같이 Member 클래스가 있을 경우 아래와 같이 테스트 작성 가능

@Test
void create_new_member{
  assertThrows(IllegalArgumentException.class, () -> new Member(-100));
}

나아가 Exception 타입으로 리턴값을 받을 경우 해당 exception을 활용가능

@Test
void create_new_member{
  IllegalArgumentException exception = 
      assertThrows(IllegalArgumentException.class, () -> new Member(-100));

  // excetpion 활용..
}

assertTimeout
시간에 대한 제한을 줄 경우 사용
```
void create_new_member{
  assertTimeout(Duration.ofSeconds(2), () -> {
      new  Member();
      Thread.sleep(3000);
  });
}
```
해당 assertion의 경우 시간제한을 2초로 주었지만, 실제 실행인 3초 이상까지 테스트가 실패하는 경우에도 실행을 하게 됩니다. 이럴 경우 사용하는 assertion이 assertTimeoutPreemptively이며 사용법은 동일합니다.
다만 ThreadLocal을 사용하는 경우 예상치 못한 예외를 발생할 수 있기 때문에 사용에 주의해야 합니다.

[web] HTTP란 HTTP의 구조 및 핵심 요소

효기로그 — Wed, 8 Jan 2020 12:42:18 +0900

HTTP

HYPERTEXT TRANSFER PROTOCOL의 약자
클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜.
80번 포트를 사용하며, TCP와 UDP를 사용한다.

여기까지가 대학생활에서 내가 이해하고 그냥 넘어갔던 부분이다. 그냥 서버와 클라이언트 상의 어떠한 규약이 있구나라고...

아래 관련 내용이 길게 나와있는데 쉽게 설명하면 클라이언트와 서버가 데이터를 일정한 규칙 ( 헤더,바디) 를 통해서 정보를 주고받는 방식이라고 생각하면 될 것 같다.

HTTP 통신 방식

1. 요청(request) - 응답(response) 방식

클라이언트(웹브라우저)가 요청을 서버에 보내면, 서버는 요청에 따른 처리 후 결과에 따른 HTTP 응답을 클라이언트에 보낸다.

2. 비상태연결(Stateless, Connectless)

HTTP 통신은 state라는 개념이 없다. 요청하고 응답을 받으면 연결을 끊어버린다. -> 서버와 클라이언트는 독립적
- 장점 : 접속유지 최소화, 연결상태 처리, 정보의 저장관리가 불필요해 서버 디자인이 간단하다.
- 단점 : 접속이 유지되지 않기 때문에 이전 통신에 정보를 알 수 없음, 따라서 로그인등과 같이 정보를 유지해야 하는 경우에도 정보 유지 불가. 이를 해결하기 위해 쿠키, 세션등을 이용

HTTP 요청(request), 응답(response)의 구조

요청 내용 : 요청 또는 요청 수행에 대한 성공 또는 실패가 기록되며, 이 줄은 항상 한줄로 끝납니다.
헤더 : 옵션으로 헤더 세트가 들어갑니다. 여기에는 요청에 대한 설명, 혹은 메세지 본문에 대한 설명이 들어갑니다.
빈줄 : 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈줄입니다.
바디(body) : 요청과 관련된 내용(HTML form 컨텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 요청 헤더에 명시됩니다.

1번과 2번을 묶어서 요청 헤드라고 부르며, 4번을 본문(body)라고 부릅니다.

요청(request) 구조

#1
POST / HTTP/1.1
#2
Host: localhost:8080       
Accept: text/html,application/xhtml+xml,application/xml;...
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)...
Content-Length: 1000
Content-Type: text/html,application/xhtml+xml,application/xml;...
#3                            
#4
{                            
    "user_name": "lee"
}

응답(response) 구조

#1
HTTP/1.1 404 Not Found
#2
Connection: close     
Content-Lenght:2000
Content-Type: text/html,application/xhtml+xml,application/xml;...
#3                            
#4
<DOCTYPE html>
<html lang=ko>
    .....
</html>

HTTP 요청 메소드

HTTP 메소드란 HTTP 통신 요청이 이루어질 때 어떠한 액션을 요청하는지 알려준다.

HTTP 메소드	요청 Body 여부	응답 Body 여부	전송형태	설명
GET	x	o	GET [request-uri] HTTP/1.1	요청받은 정보를 검색하여 응답
HEAD	x	x	HEAD[request-uri] HTTP/1.1	GET과 동일하지만 응답에 BODY없이 응답코드, HEAD만 응답
POST	o	o	POST[request-uri] HTTP/1.1	자원 생성(CREATE)에 사용
PUT	o	o	PUT[request-uri] HTTP/1.1	자원 전체 수정(UPDATE)에 사용
PATCH	x	o	PATCH[request-uri] HTTP/1.1	PUT과 동일하게 수정에 사용되지만, 해당 자원의 일부 수정시 사용
DELETE	o	o	DELETE[request-uri] HTTP/1.1	자원 삭제(DELETE)에 사용
CONNECT	선택사항	o	CONNECT[request-uri] HTTP/1.1	동적으로 터널 모드 교환, 프록시 기능을 요청시에 사용
TRACE	x	o	TRACE[request-uri] HTTP/1.1	원격ㅣ 서버에 프백 메세지 호출을 위해 테스트용으로 사용
OPTIONS	o	o	OPTIONS[request-uri] HTTP/1.1	웹서버에서 지원되는 메소드 종류를 확인할 경우 사용

참고
- POST / PUT : POST는 멱등하지 않고, PUT는 멱등하다. 즉, 동일한 자원을 여러번 POST할 경우 서버 자원에 변화가 생기지만 PUT는 변화가 생기지 않는다.
- PUT / PATCH : PUT는 전체 자원을 수정하기 동일한 수정일 경우 멱등하고, PATCH의 경우 일부가 변경되기 때문에 멱등하지 않는다.

멱등성 : 같은 작업을 반복해도 같은 결과가 나오는지 여부

HTTP 응답 코드

클라이언트가 요청하면 서버는 결과를 응답 코드와 함께 응답하게 된다.

코드	메세지	설명
1XX (ex 100,101)	Informational(정보)	정보 교환
2XX (ex 200,202,203)	Success(성공)	데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음
3XX (ex 300,301,302)	Redirection(방향 변경)	자료의 위치가 변경되었음
4XX (ex 400,404)	Client Error(클라이언트 오류)	클라이언트 측 오류
5XX (ex 500,505)	Server Error(서버 오류)	서버 측의 오류

HTTL 주요 헤더 종류

공통 헤더 - 요청(request), 응답(response) 둘다 사용

Date : HTTP 메세지를 생성할 일시
Connection : 클라이언트와 서버 연결에 대한 설정
- Connection: close : 통신 직후 TCP 접속 종료
- Connection: Keep-Alice : 현재 TCP 커넥션 유지
Cache-Control
- Cache-Control: no-store : 캐시 미사용
- Cache-Control: no-cache : 서버에게 확인 후 사용
- Cache-Control: must-revalidate : 만료된 캐시만 서버에서 확인
- Cache-Control: public : 공유 캐시에 저장가능
- Cache-Control: private : '브라우저' 같은 특정 사용자 환경에만 저장
- Cache-Control: max-age : 캐시 유효시간을 명시
Pragma : HTTP/1.0에서 사용하던 캐시 제어
Content-Type, Content-Encoding, Content-Length, Content-Language : 본문 설정

요청 헤더

Host : 요청하려는 uri 정보
User-agnet : 클라이언트 프로그램 정보 ex) 브라우저 정보
Referer : 직전에 머물러 있던 페이지 정보
Accept, Accept-charset, Accept-language, Accept-encoding : 클라이언트 정보
Authorization : 인증 토큰 정보
Origin : 맨 처음 시작 요청 주소값
Cookie : 쿠기 값

응답 헤더

Location : 301,302 에 사용되는 해더로, 변경된 주소를 지정
Server : 웹서버의 종류
Age : max-age 시간에서 얼마나 지났는지 (초단위)

그 외 헤더 자료들은 많기 때문에 추가로 필요한 정보는 검색을 통해서 알아보시면 될 것 같습니다.

참고 자료

https://ko.wikipedia.org/wiki/HTTP
https://jeong-pro.tistory.com/181?category=822281
https://javaplant.tistory.com/18
https://developer.mozilla.org/ko/docs/Web/HTTP/

[독서리뷰] Head First Design Pattern 스토리가 있는 패턴 학습법

효기로그 — Fri, 3 Jan 2020 17:10:02 +0900

이전에 JAVA 언어로 배우는 디자인 패턴 입문 이라는 책을 공부하면서 말그대로 입문 서적이였기 때문에 가끔 부족한 설명이 느껴져서 매번 관련 래퍼런스를 검색해가며 공부를 병행했었다 자주 방문한 래퍼런스는 https://refactoring.guru/design-patterns

Design Patterns

refactoring.guru

각종 찬사들

스콧 맥닐리, 썬 마이크로시스템즈 회장 : 자바 기술은 모든 곳에 쓰입니다.....
켄 아놀드, 썬 마이크로시스템즈 시니어 엔지니어 : 빠르고 재미있고 정신없는 책입니다......
로스 골드버그 : 정말 놀라운 학습법입니다. 도저히 책을 내려놓을 수 없었어요.....
폴로이드 존슨 : 너무 좋아서 눈물이 막 나오려고 해요....

위와같은 인용구로 책을 시작합니다.

저자/개발자 소개

엘리자배스 프리먼 : 소프트웨어 개발자이자 디지털 아티스트
에릭 프리먼 : 미디어 및 소프트웨어 아키텍처 전문 전산학자
케이시 시에라 : 게임디자이너
버트 베이츠 : 소프트웨어 개발자 및 아키텍트

디자인 패턴의 세계에 오신 것을 환영합니다 : 디자인 패턴 소개
객체들에게 연락망을 돌립시다 : 옵저버 패턴
객체 꾸미기 : 데코레이터 패턴
객체지향 빵 굽기 : 팩토리 패턴
세상에 단 하나뿐인 특별한 객체 : 싱글턴 패턴
호출 캡술화 : 커맨드 패턴
적응 시키기 : 어댑터 패턴과 퍼사드 패턴
알고리즘 캡슐화 : 템플릿 메소드 패턴
잘 관리된 컬렉션 : 이터레이터와 컴포지트 패턴
객체의 상태 : 스테이트 패턴
객체 접근 제어 : 프록시 패턴
패턴들로 이루어진 패턴 : 컴파운드 패턴
실전에서의 디자인 패턴 : 패턴과 함께 하는 행복한 ㅅ람
부록 : 기타 패턴

마치며

확실히 인용구에 나와 있는 말처럼 처음에 책을 읽을 때 정신이없고, 전혀 눈에 들어오지 않아서 고생이 많았다.
그러나 여러 그림, 계속되는 질문, 연관되어 있는 스토리를 통한 설계 등 여러 신박한 방식으로 책을 풀어가고 해당 패턴에 대한 설명도 엄청 자세하게 설명되어 있고 객체 지향의 근본적인 접근과, 디자인 패턴의 원칙으로 설명을 하니까 왜 하는지에 대한 이해가 확실한 것 같다.
다만 아쉬운 점으론 해당 패터 하나하나 자세히 설명하다 보니 전부다 설명을 못하고...그래도 670페이지 가량 된다.
기타 패턴으로 간략하게 설명만 하고 넘어가는데 그 부분은 추가로 공부가 필요할 것 같다
전체적으로 엄청 만족하고 강추하는 책이다.. 기타 부록에 있는 패턴도 2탄으로 나왔으면 좋겠다는 생각이 드는 책.....

마지막으로 자세한 내용은 해당 책을 구매하는것을 추천합니다. 강추!!하며, 관련 내용은 저의 블로그 디자인패턴 카테고리를 통해 확인이 가능합니다.

[독서리뷰] JAVA 언어로 배우는 디자인 패턴 입문 - 유키 히로시

효기로그 — Fri, 3 Jan 2020 16:45:44 +0900

자바 공부를 진행하는 도중 여러 서적에서 심심치 않게 등장하는 디자인 패턴 특히 스프링을 공부하다 보면 많이 접하게 되는 것 같습니다. 그래서 도대체 디자인 패턴이 뭔데?라는 생각에 google의 여러 지식인 분들의 도움을 받아 하나하나 포스팅을 보게 되었지만, 내용이 생각보다 방대해서 책으로 공부를 해야겠다고 마음먹었습니다.
여러 서적 중 많은 고민이 있었지만, okky에 나와 같은 고민을 한 사람들이 상당히 존재했고, 초보 개발자가 보기엔 해당 책이 설명이 좋다는 글을 보고 알아보니 구성이 괜찮아 보여서 구매를 진행하였다.

이 책의 특징

Java 언어에 의해 실제로 움직이는 예제 프로그램
패턴 이름의 해설
패턴 간의 관련과 연습문제
Java 언어의 관련 정보
패턴의 일러스트

이 책의 독자

해당 책은 아래와 같은 독자를 대상으로 합니다.

객체 지향에 관심이 있는 사람
디자인 패턴에 관심이 있는 사람( 특히, GoF의 책을 보고 어렵다고 느낀 사람 )
Java 프로그래머( 특히, 추상 클래스나 인터페이스의 이해가 부족한 사람 )

그 외

해당 책의 예제 프로그램도 제공해주고 모든 프로그램은 public static void main(String[] args) 즉 매인 메소드를 통해서 예제를 풀어가는 방식으로 진행되는 책입니다.

마치며

책의 간단한 소개는 마무리하고, 자세한 내용은 저의 디자인 패턴 카테고리를 이용하시거나 제일 좋은 방법은 관련 서적을 구매해서 공부해보시는 것을 추천합니다.
입문 난이도를 기준으로 잡았기 때문에 해당 패턴에 대한 개념과 원리에 대한 설명은 충분하지만, 좀 더 구체적인 내용은 다른 서적을 이용하거나 관련 적용된 Open Source를 보면서 이해를 해야겠다는 생각이 들었습니다.
그래도 디자인 패턴이 무엇인지 어떤 게 있는지 각각의 사용 이유와 어느 정도 객체지향에 대해서 조금은 친근해진 느낌이 드는 책이었습니다. 전체적으로 초보자에게 추천하는 책입니다.

[TDD/테스트주도개발] TDD 개념

효기로그 — Fri, 3 Jan 2020 16:17:47 +0900

테스트 주도 개발 TDD 실천법과 도구 정리한 내용입니다. 해당 내용은 Junit4 버전을 기준으로 설명합니다.
책이 절판됨에 따라 저자인 채수원님께서 무료로 PDF를 공개하셨으니 블로그에서 관련 자료 다운로드가 가능합니다.
또한 책이 2010년에 출간되었다는 점에서 저자분이 해당 내용에 보충할 만한 내용도 같이 정리해서 올려주시니 관련 링크를 통해서 참고하시는게 제일 좋은 방법일 것 같습니다.

https://repo.yona.io/doortts/blog/issue/1

테스트 주도 개발
JUnit과 Hamcrest
TDD 좀 더 잘하기
한계 돌파를 위한 노력, Mock을 이용한 TDD
데이터베이스 테스트 : DbUnit
단위 테스트 지원 라이브러리 : Unitils
개발 영역에 따른 TDD 작성 패턴
TDD에 대한 다양한 시작
자주 접하게 되는 질문들, FAQ
실습 예제
테스트 자동화와 커버리지
부록

1. 테스트 주도 개발

1-1. TDD란?

Test Driven Development의 약자로 말 그대로 테스트 주도 개발이라는 언어입니다.
즉 기존의 SW를 개발하고 테스트를 하는 방식이 아닌, 테스트부터 작성하면서 코드를 작성하는 방법을 말합니다.

1-2. TDD 개발의 진행 방식

해당 책에서는 TDD를 크게 3가지의 단계가 반복적으로 이루어진다고 설명하고 있습니다.

* 질문 : 테스트 작성을 통해 시스템에 질문 ( 테스트 실패 )  
* 응답 : 테스트를 통과하는 코드를 작성해서 질문에 대답한다 ( 테스트 성공 )
* 정체 : 통합, 불필요한 부분 제거 등의 리팩토링
* 반복 : 위 3가지를 반복을 통해 계속 작성해 나간다.

1-3. TDD의 간단한 실습 예제

아래와 같은 테스트가 필요하다고 정의합니다.

1. Member 클래스 필요
2. Member의 기능
    * ID 받아오기
    * 비밀번호 암호화하기
    * 기타등등..
3. 기타 등..

최초로 프로젝트를 생성 후, 임시로 Test 클래스를 하나 작성해봅니다. 그리고 annotation으로 @Test를 선언해주고 메소드를 하나 만들어줍니다. 그 후 아래와 같은 질문을 통해서 테스트 케이스를 작성합니다.

public class TestAccount() {
    @Teest
    public void testMember() {
           Member member = new Member();
    }
}

위와같이 작성 후 JUnit4으로 실행을 합니다. Membmer 클래스가 정의되어 있지 않은 상태에서 인스턴스화 하려고 하니 당연히 오류가 발생합니다. 이 단계가 질문에 해당합니다.
이제 응답 단계입니다. 어려울거 없이 Member클래스를 생성해주면 그만입니다. 그리고 임의의 요구에 따라서 null이면 안되는 객체이기 때문에 조건을 추가해줍니다.

public class TestAccount {
    @Test
    public void testMember() throws Exception {
        Member member = new Member();
        if(member == null) {
            throw new Exception("member 생성 실패!");
        }
        // 또는
        assertNotNull(member);
    }
}

마지막으로 정제(리팩토링) 단계입니다. 통상적으로 아래와 같은 고민 후 소스를 리팩토링해줍니다.

소스의 가독성이 적절한가?
중복된 코드는 없는가?
이름이 잘못 부여된 메소드나 변수명은 없는가?
구조의 개선이 필요한 부분은 없는가?

자 이제 저희는 위 예제에서 개선이 필요한 부분은 없는가? 에서 한가지 제거할 코드가 존재합니다.
사실 new 연산자를 통해 인스턴스 생성 시 오류가 발생하면 자동으로 Exception이 발생하고, 그 상황을 JUnit가 처리하기 때문에 null인지 체크하는 부분은 더 이상 필요가 없어집니다.

public class TestAccount {
    @Test
    public void testMember() throws Exception {
        Member member = new Member();
    }
}

여기까지가 질문 1인 Member 클래스 검증 부분을 끝마쳤습니다. 사실 예제가 간단해서 억지스러운 부분도 존재하지만, TDD를 어떤식으로 진행하는지에 대한 감익히기가 목표이기 때문에 전체적은 느낌을 이해하셨다면 성공이라고 생각합니다.

1-4. TDD 장점

개발의 방향을 잃지 않게 유지해준다.
품질 높은 소프트웨어 모듈 보유, 시스템 결함이 줄어든다.
자동화된 단위 테스트 케이스를 갖게 된다. 유지보수 용이
사용설명서 & 의사소통의 수단, 테스트 문서로 사용 가능
설계 개선. 필자가 제일 강조하며, 본인이 얼마나 의존적이고 즉흥적인 설계를 하고 있는지 체감할 수 있다고 한다...
TDD는 주기를 짧게 설정하도록 권장해서, 성공했다는 성취감을 얻음으로써 능률을 향상 시킨다.

1-5. 엉클 밥의 TDD 원칙

엉클 밥은 로버트 마틴(Robert C. Martin)으로 객체 지향 개발의 선구자로 유명하다. 이 분이 권장하는 TDD의 원칙 3가지를 소개합니다.

실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.
실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.
현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘어서는 제품 코드를 작성하지 않는다.

3번은 의외인것 같다. 추후 사용해보면서 체감을 할 수 있기를 바라면서

[자바/알고리즘] 프로그래머스 탑

효기로그 — Thu, 2 Jan 2020 14:17:35 +0900

문제 설명

수평 직선에 탑 N대를 세웠습니다. 모든 탑의 꼭대기에는 신호를 송/수신하는 장치를 설치했습니다. 발사한 신호는 신호를 보낸 탑보다 높은 탑에서만 수신합니다. 또한, 한 번 수신된 신호는 다른 탑으로 송신되지 않습니다.
$nbsp;예를 들어 높이가 6, 9, 5, 7, 4인 다섯 탑이 왼쪽으로 동시에 레이저 신호를 발사합니다. 그러면, 탑은 다음과 같이 신호를 주고받습니다. 높이가 4인 다섯 번째 탑에서 발사한 신호는 높이가 7인 네번째 탑이 수신하고, 높이가 7인 네 번째 탑의 신호는 높이가 9인 두 번째 탑이, 높이가 5인 세 번째 탑의 신호도 높이가 9인 두 번째 탑이 수신합니다. 높이가 9인 두 번째 탑과 높이가 6인 첫 번째 탑이 보낸 레이저 신호는 어떤 탑에서도 수신 할 수 없습니다.

송신 탑(높이)	수신 탑(높이)
5(4)	4(7)
4(7)	2(9)
3(5)	2(9)
2(9)	-
1(6)	-

맨 왼쪽부터 순서대로 탑의 높이를 담은 배열 heights가 매개변수로 주어질 때 각 탑이 쏜 신호를 어느 탑에서 받았는지 기록하는 배열을 return하도록 solution 함수를 작성해주세요.

제한 사항

heights는 길이 2 이상 100 이하인 정수 배열입니다.
모든 탑의 높이는 1 이상 100 이하입니다.
신호를 수신하는 탑이 없으면 0으로 표시합니다.

입출력 예

heights	return
[6,9,5,7,4]	[0,0,2,2,4]
[3,9,9,3,5,7,2]	[0,0,0,3,3,3,6]
[1,5,3,6,7,6,5]	[0,0,2,0,0,5,6]

입출력 예 설명

입출력 예 #1
- 앞서 설명한 예와 같습니다.
입출력 예 #2
- [1,2,3] 번째 탑이 쏜 신호는 아무도 수신하지 않습니다.
- [4,5,6] 번째 탑이 쏜 신호는 3번째 탑이 수신합니다.
- [7] 번째 탑이 쏜 신호는 6번째 탑이 수신합니다.
입출력 예 #3
- [1,2,4,5] 번째 탑이 쏜 신호는 아무도 수신하지 않습니다.
- [3] 번째 탑이 쏜 신호는 2번째 탑이 수신합니다.
- [6] 번째 탑이 쏜 신호는 5번째 탑이 수신합니다.
- [7] 번째 탑이 쏜 신호는 6번째 탑이 수신합니다.

나의 풀이

class Solution {
    public int[] solution(int[] heights) {
       int[] answer = new int[heights.length];
        for (int i = 1; i < heights.length; i++) {
            for (int j = i; j >= 0; j--) {
                if(heights[i] < heights[j]) {
                    answer[i] = j+1;
                    break;
                }
            }
        }
        return answer;
    }
}

풀이 설명

정답 배열을 순차적으로 기록하기 위해 바깥(i) 반복문은 1 ~ 배열의 크기 까지 반복문을 돌렸고
몇번째 탑에서 송신하는지는 왼쪽으로 신호를 보내기 위해서 i ~ 0 까지 반복문을 돌려서 정답이 될 배열에 기록 후 리턴하는 방식으로 문제를 풀었습니다.

[디자인패턴/Design Pattern] Flyweight Pattern / 플라이웨이트 패턴

효기로그 — Tue, 31 Dec 2019 14:31:16 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문],[Head First Design Pattern]의 내용을 참고해서 정리한 글입니다.
잘못된 부분은 댓글로 피드백 부탁드립니다.

1. Flyweight 패턴이란?

어떤 클래스의 인스턴스 한 개만 가지고 여러 개의 "가상 인스턴스"를 제공하고 싶을 때 사용하는 패턴입니다.
즉 인스턴스를 가능한 대로 공유시켜 쓸데없이 new연산자를 통한 메모리 낭비를 줄이는 방식입니다.

2. Flyweight 패턴의 등장인물

Flyweight(플라이급)의 역할
1. 공유에 사용할 클래스들의 인터페이스(API)를 선언합니다.
ConcreteFlyweight(구체적인 플라이급)의 역할
1. Flyweight의 내용을 정의합니다. 실제 공유될 객체입니다.
FlyweightFactory(플라이급의 공장)의 역할
1. 해당 공장을 사용해서 Flyweight의 인스턴스를 생성 또는 공유해주는 역할을 합니다.
Client(클라이언트)의 역할
1. 해당 패턴의 사용자 입니다.

Flyweight 패턴의 클래스 다이어그램

3. 예제

3-1. Shape 인터페이스

public interface Shape {
    public void draw();
}

해당 패턴을 적용할(공유로 사용될) 클래스들의 인터페이스(API)를 작성합니다.

3-2. Circle 클래스

public class Circle implements Shape {
    private String color;
    private int x;
    private int y;
    private int radius;

    public Circle(String color) {
        this.color = color;
    }

    public void setColor(String color) {
        this.color = color;
    }

    public void setX(int x) {
        this.x = x;
    }

    public void setY(int y) {
        this.y = y;
    }

    public void setRadius(int radius) {
        this.radius = radius;
    }

    @Override
    public void draw() {
        System.out.println("Circle [color=" + color + ", x=" + x + ", y=" + y + ", radius=" + radius + "]");
    }
}

ConcreteFlyweight에 해당하며 인터페이스(API)의 내용을 정의하고, 필요한 속성을 가질 수 있습니다.

3-3. ShapeFactory 클래스

public class ShapeFactory {
    private static final HashMap<String, Circle> circleMap = new HashMap<>();

    public static Shape getCircle(String color) {
        Circle circle = (Circle)circleMap.get(color);

        if(circle == null) {
            circle = new Circle(color);
            circleMap.put(color,circle);
            System.out.println("==== 새로운 객체 생성 : " + color + "색 원 ====" );
        } 

        return circle;
    }
}

getCircle()메소드를 통해 객체의 생성 또는 공유의 역할을 담당하며 클라이언트에게 응답해줍니다.

3-4. Main 클래스

public class Main {
    public static void main(String[] args) {
        String[] colors = {"Red","Green","Blue","Yellow"};

        for (int i = 0; i < 10; i++) {
            Circle circle = (Circle)ShapeFactory.getCircle(colors[(int) (Math.random()*4)]);
            circle.setX((int) (Math.random()*100));
            circle.setY((int) (Math.random()*4));
            circle.setRadius((int) (Math.random()*10));
            circle.draw();
        }
    }
}

실행 결과

==== 새로운 객체 생성 : Yellow색 원 ====
Circle [color=Yellow, x=76, y=2, radius=4]
Circle [color=Yellow, x=19, y=2, radius=8]
==== 새로운 객체 생성 : Red색 원 ====
Circle [color=Red, x=38, y=2, radius=2]
Circle [color=Red, x=41, y=0, radius=1]
Circle [color=Yellow, x=58, y=3, radius=2]
Circle [color=Yellow, x=31, y=0, radius=6]
==== 새로운 객체 생성 : Blue색 원 ====
Circle [color=Blue, x=7, y=3, radius=7]
Circle [color=Blue, x=84, y=2, radius=1]
Circle [color=Yellow, x=90, y=2, radius=2]
==== 새로운 객체 생성 : Green색 원 ====
Circle [color=Green, x=34, y=0, radius=2]

로직에 의해 같은 색상의 원은 1개만 생성되며 생성된 객체를 공유하는걸 확인할 수 있습니다.

그렇다면 왜 사용할까?

실행시에 객체 인스턴스의 개수를 줄여서 메모리를 절약할 수 있습니다,
여러 "가상" 객체의 상태를 한 곳에 집중시켜놓을 수 있습니다.

즉 어떤 클래스의 인스턴스가 아주 많이 필요하지만 모두 똑같은 방식으로 제어할 수 있는 경우에 유용하게 사용됩니다,
그러나 아래와 같은 단점이 존재합니다.

특정 인스턴스만 다른 인스턴스처럼 동작하도록 하는 것이 불가능
객체의 값을 변경하면 공유받은 "가상" 객체를 사용하는 곳에 영향을 줄 수 있습니다.

4. 관련 패턴

Proxy 패턴 : Flyweight 패턴에서는 인스턴스의 생성에 시간이 걸리는 경우, 인스턴스의 공유에 따라서 처리 속도가 향상됩니다. link
Composite 패턴 : Flyweight 패턴을 사용해서 Composite 패턴의 Leaf 역할을 공유시킬 수 있는 경우가 있습니다. link
Singleton 패턴 : FlyweightFactory를 Singleton으로 구현하는 경우가 있습니다. link

[디자인패턴/Design Pattern] Chain of Responsibility 역할 사슬 패턴

효기로그 — Tue, 31 Dec 2019 10:46:24 +0900

1. Chain of Responsibility 패턴이란?

요청이 주어질때, 사슬에 속해있는 각 객체는 자기가 받은 요청을 검사하여 직접 처리하거나 사슬에 들어있는 다른 객체에 넘기게 되는 방식. 즉 책임을 넘기는 구조입니다.

2. Chain of Responsibility 패턴의 등장인물

Handler(처리자)의 역할
1. 요구를 처리하는 인터페이스(API)를 결정하는 역할을 합니다.
ConcreteHandler(구체적인 처리자)의 역할
1. 요구를 처리하는 구체적인 역할을 합니다.
Clinet(요구자)의 역할
1. 최초의 ConcreteHandler 역할에 요구하는 일을 합니다.

Chain of Responsibility 클래스 다이어 그램

3. 예제

3-1. Trouble 클래스

무언가 요청을 표현할 클래스입니다.

public class Trouble {
    private int number;

    public Trouble(int number) {
        this.number = number;
    }

    public int getNumber() {
        return number;
    }

    @Override
    public String toString() {
        return "Trouble [number=" + number + "]";
    }
}

3-2. Support 추상 클래스

트러블(요청)을 해결할 사슬을 만들기 위한 추상 클래스입니다. next라는 필드를 통해서 떠넘기는 곳을 지정하고, 필요하면 트러블(요청)을 떠넘기는 곳을 setNext() 메소드로 설정합니다.

public abstract class Support {
    private String name;
    private Support next;

    public Support(String name) {
        this.name = name;
    }

    public Support setNext(Support next) {
        this.next = next;
        return next;
    }

    public final void support(Trouble trouble) {
        if (resolve(trouble)) {
            done(trouble);
        } else if (next != null) {
            next.support(trouble);
        } else {
            fail(trouble);
        }
    }

    @Override
    public String toString() {
        return "Support [name=" + name + "]";
    }

    protected abstract boolean resolve(Trouble trouble);

    protected void done(Trouble trouble) {
        System.out.println(trouble + " is resolved by " + this);
    }

    protected void fail(Trouble trouble) {
        System.out.println(trouble + " cannot be resolved");
    }
}

support() 메소드를 통해서 트러블(요청)에 대한 처리 수순을 정의했습니다. 또한 실제 처리 부분인 resolve()메소드는 추상 메소드로 선언해 하위 클래스에서 구체적인 구현을 위임합니다.

3-3. NoSupport, LimitSupport, OddSupport, SpecialSupport 추상 클래스

각각 Support 추상 클래스의 하위 클래스입니다. 필요한 로직을 수행합니다.

public class NoSupport extends Support {
    public NoSupport(String name) {
        super(name);
    }

    @Override
    protected boolean resolve(Trouble trouble) {
        return false;
    }
}

public class OddSupport extends Support {

    public OddSupport(String name) {
        super(name);
    }

    @Override
    protected boolean resolve(Trouble trouble) {
        if(trouble.getNumber() % 2 == 1) {
            return true;
        } 
        return false;
    }
}

public class SpecialSupport extends Support {
    private int number;

    public SpecialSupport(String name, int number) {
        super(name);
        this.number = number;
    }

    @Override
    protected boolean resolve(Trouble trouble) {
        if(trouble.getNumber() == number) {
            return true;
        }
        return false;
    }
}

public class LimitSupport extends Support {
    private int limit;

    public LimitSupport(String name, int limit) {
        super(name);
        this.limit = limit;
    }

    @Override
    protected boolean resolve(Trouble trouble) {
        if (trouble.getNumber() < limit) {
            return true;
        }
        return false;
    }
}

3-4. Main 클래스

Support 클래스를 통해 사슬을 생성하고, 트러블(요청)을 수행하는 매인 클래스입니다.

public class main {
    public static void main(String[] args) {
        Support alice = new NoSupport("Alice");
        Support bob = new LimitSupport("Bob", 100);
        Support charlie = new SpecialSupport("Charlie", 429);
        Support diana = new LimitSupport("Diana",200);
        Support elmo = new OddSupport("Elomo");
        Support fred = new LimitSupport("Fred",300);

        alice.setNext(bob).setNext(charlie).setNext(diana).setNext(elmo).setNext(fred);

        for (int i = 0; i < 500; i++) {
            alice.support(new Trouble(i));    
        }
    }
}

실행 결과

Trouble [number=0] is resolved by Support [name=Bob]
Trouble [number=1] is resolved by Support [name=Bob]
Trouble [number=2] is resolved by Support [name=Bob]
....
Trouble [number=498] cannot be resolved
Trouble [number=499] is resolved by Support [name=Elomo]

그렇다면 왜 사용할까?

요청을 보낸 쪽하고 받는 쪽을 분리시킬 수 있습니다.
객체에서는 사슬의 구조를 몰라도 되고 그 사슬에 들어있는 다른 객체에 대한 직관적인 래퍼런스를 가질 필요도 없기 때문에 객체를 단순하게 만들 수 있습니다.
사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로써 역할을 동적으로 추가/제거할 수 있습니다.

윈도우 시스템에서 마우스 클릭이나 키보드 이벤트를 처리할 때 흔하게 사용됩니다. 그러나 아래와 같은 단점도 존재합니다.

실행시에 과정을 살펴보거나 디버깅하기가 힘들 수 있다는 단점이 있습니다.
요청이 반드시 수행된다는 보장이 없습니다. 사슬의 끝이여도 어느 객체에서도 처리를 못하는 경우 ( 장점이 될 수도 )

4. 관련 패턴

Composite 패턴 : Handler 역할에 Composite 패턴이 자주 등장합니다. link
Command 패턴 : Hanlder 역할에 대해서 제공되는 '요구'에는 Command 패턴이 사용되는 경우가 있습니다.

[디자인패턴/Design Pattern] Builder 패턴 / 빌더 패턴

효기로그 — Mon, 30 Dec 2019 15:46:23 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문],[Head First Design Pattern],[Effective Java 3 개정판]의 내용을 참고해서 정리한 내용입니다.
잘못된 부분은 댓글로 피드백 부탁드립니다.

1. Builder 패턴이란?

객체의 생성 단계들을 캡슐화 하여 객체의 생성을 유연하게 해주는 패턴입니다. 즉 객체의 생성과정과 객체의 표현 방법을 분리합니다.

2. Builder 패턴의 등장인물

Builder(건축자)의 역할
1. 인스턴스 생성을 위한 인터페이스(API)를 선언합니다.
ConcreteBuilder(구체적인 건축자)의 역할
1. Builder 인터페이스를 구현하는 역할을 합니다.
Director(감독자)의 역할
1. Builder 인터페이스(API)를 사용해 인스턴스를 사용합니다.
Productor(제품)의 역할
1. 만들어질 제품의 속성과 기능을 가집니다.

Builder 패턴의 클래스 다이어그램

3. 예제

3-1. Builder 추상 클래스

제품을 필드로 가지며 객체 생성시 필요한 메소드를 선언하는 추상 클래스입니다.

public abstract class Builder {
    protected House house;

    public void createHouse() {
        house = new House();
    }

    public abstract void buildWalls();

    public abstract void buildDoors();

    public abstract void bouildRoof();

    public abstract void buildWindoes();

    public abstract House getHouse();
}

3-2. House 클래스

제품 클래스입니다. 생성될 제품의 속성과 기능을 가집니다.

public class House {
    private String roof;
    private String doors;
    private String windows;
    private String walls;

    public void setRoof(String roof) {
        this.roof = roof;
    }

    public void setDoors(String doors) {
        this.doors = doors;
    }

    public void setWindows(String windows) {
        this.windows = windows;
    }

    public void setWalls(String walls) {
        this.walls = walls;
    }

    @Override
    public String toString() {
        return "이집은 [" + roof + " 지붕과, " + walls + " 벽과, " + windows + "창문과 ," + doors + "문으로로 지어진 집입니다.]";
    }    
}

3-3. ConcreteHouseBuilder, WoodHouseBuilder 클래스

각각 Builder 추상 클래스의 기능을 재정의합니다.

public class ConcreteHouseBuilder extends Builder {

    @Override
    public void buildWalls() {
        house.setWalls("콘트리트");
    }

    @Override
    public void buildDoors() {
        house.setDoors("철제");
    }

    @Override
    public void bouildRoof() {
        house.setRoof("빨간 ");
    }

    @Override
    public void buildWindoes() {
        house.setWindows("일반 ");
    }

    @Override
    public House getHouse() {
        return house;
    }
}

public class WoodHouseBuilder extends Builder {

    @Override
    public void buildWalls() {
        house.setWalls("통나무");
    }

    ....

    @Override
    public House getHouse() {

        return house;
    }
}

3-4. Director 클래스

Builder을 속성으로 가지며, Builder 클래스의 메소드를 사용해 객체를 생성하고, 반환해줍니다.

public class Director {
    private Builder builder;

    public Director(Builder builder) {
        this.builder = builder;
    }

    public void build() {
        builder.createHouse();
        builder.buildWalls();
        builder.buildWindoes();
        builder.buildDoors();
        builder.bouildRoof();
    }

    public House getHouse() {
        return builder.getHouse();
    }
}

3-5. Main 클래스

public class Main {
    public static void main(String[] args) {
        Builder concreteHouseBuilder = new ConcreteHouseBuilder();
        Director director = new Director(concreteHouseBuilder);
        director.build();

        House house1 = director.getHouse();
        System.out.println(house1);

        Builder woodHouseBuilder = new WoodHouseBuilder();
        director = new Director(woodHouseBuilder);
        director.build();

        House house2 = director.getHouse();
        System.out.println(house2);

    }
}

실행 결과

이집은 [빨간 철제 지붕과, 콘트리트 벽과, 일반 창문과 ,철제문으로 지어진 집입니다.]
이집은 [기와장  지붕과, 통나무 벽과, 나무 창문과 ,원목 나무문으로 지어진 집입니다.]

그렇다면 왜 사용할까?

이렇게 객체의 생성과정과 객체의 표현 방법을 분리하여 사용함으로써 다음과 같은 조합으로 객체 생성이 가능해집니다.

	콘크리트를 사용하는 Builder	나무를 사용하는 Builder
집을 만드는 Director	콘크리트 집	나무 집
학교를 만드를 Director	콘크리트 학교	나무 학교

사실 예제가 억지에 가깝지만.. 대충 이해한 내용을 코드로 작성해봤습니다.
이제 [Effective java]에서 소개하는 Builder Pattern을 소개하겠습니다.

4. Effective Builder 패턴

책에는 생성자 인자가 많을 경우 Builder 패턴 적용을 고려하라 라고 안내합니다. 즉 해당 책에서는 Builder 패턴을 객체 생성을 깔끔하고, 유연하게 할 수 있는 방법을 소개해줍니다.

4-1. 점층적 생성자 패턴

public class Member {
    private final String name ;
    private final Integer age;

    public Member(String name) {
        this(name, null);
    }

    public Member(String name, Integer age) {
        this.name = name;
        this.age = age;
    }
}

위 코드와 같은 클래스에서 새로운 필드인 주소, 이메일, 핸드폰 번호가 추가 되었을 경우 생성자를 어떻게 만들어야 할까? 생각만해도 머리가 아픕니다.. 이름과 이메일만 가지는 생성자, 이름과 핸드폰 번호만 가지는 생성자.......
또한, Member m = new Member("Lee",10,2)와 같이 생성자를 사용할 경우 각각의 인자가 무엇을 의미하는지 직관적으로 파악하기가 힘듭니다.
그래서 등장한 방식이 자바빈 패턴입니다.

4-2 JavaBeans Pattern

public class Member {
    private String name;
    private Integer age;

    public String getName() {
        return name;
    }

    public Integer getAge() {
        return age;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setAge(Integer age) {
        this.age = age;
    }
}

public class Main {
    public static void main(String[] args) {
        Member m = new Member();
        m.setName("Lee");
        m.setAge(20);
    }
}

해당 패턴을 통해 객체를 생성함으로써 불필요한 생성자가 필요가 없어졌고, 각각 메소드의 인자가 어떤 인자인지 메소드명을 통해서 파악하기 쉬워졌습니다.
그러나 setter을 통해 객체의 값이 변경 가능하기 때문에 immutable 클래스를 만들 수가 없고, 객체의 호출을 1번이 아닌 여러번을 하게 되는 단점이 있습니다

4-2 Effective java Builder Pattern

마지막으로 대망의 Effective java에서 소개하는 Builder Pattern의 방식입니다.

public class Member {

    private final String name;
    private final int age;
    private final String address;

    public static class Builder {
        // 필수 인자
        private final String name;

        private int age = 0;
        private String address = "";

        public Builder(String name) {
            this.name = name;
        }

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public Builder address(String address) {
            this.address = address;
            return this;
        }

        public Member build() {
            return new Member(this);
        }
    }

    private Member(Builder builder) {
        name = builder.name;
        age = builder.age;
        address = builder.address;
    }

    @Override
    public String toString() {
        return "Member [name=" + name + ", age=" + age + ", address=" + address + "]";
    }
}

public class Main {
    public static void main(String[] args) {
        Member member = new Member
                .Builder("Lee") // 필수 인자
                .age(20)
                .address("Korea")
                .build(); // 객체 생성

        System.out.println(member);
    }
}

위 코드와 같이 객체를 생성할 수 있는 방식을 제공합니다. 해당 방식을 사용하면 아래와 같은 이점이 있습니다.

각 인자를 파악하기 쉽다.
setter 메소드가 없으므로 변경 불가능 클래스 작성 가능
객체의 일관성이 깨지지 않습니다. 한번만 호출
build() 메소드를 통해 값이 잘못 되었는지 검증 가능

Lombok이라는 라이브러리의 link @Builder 도 해당 방식의 빌더를 자동으로 생성해줍니다.

5. 관련 패턴

Template Method 패턴 : Builder 패턴에서는 Director이 Builder을 제어합니다. 반면 해당 패턴은 사위 클래스가 하위 클래스를 제어합니다. link
Composite 패턴 : Builder 패턴에 의해 만들어진 생성물은 해당 패턴이 되는 경우가 있습니다. link
Abstract Factory 패턴 : 동일하게 복잡한 인스턴스 생성을 담당합니다,
Facade 패턴 : Builder는 인스턴스 생성을 단순한 인터페이스(API)를 제공. 해당 패턴은 내부 모듈을 간단하게 사용하기 위한 인터페이스(API)를 제공합니다. link

[디자인패턴/Design Pattern] Bridge Pattern / 브리지 패턴

효기로그 — Thu, 26 Dec 2019 07:52:12 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문],[Head First Design Pattern]의 내용을 참고해서 정리한 내용입니다. 잘못된 부분은 댓글로 피드백 부탁드립니다.

1. Bridge 패턴이란?

'기능 클래스 계층'과 '구현 클래스 계층'을 연결해주는 패턴입니다.

기능 클래스 계층이란 ?
- A라는 상위 클래스를 상속받는 B라는 하위 클래스에서 새로운 기능을 추가하는 계층을 말합니다.
구현 클래스 계층이란 ?
- A라는 인터페이스(API)를 구현한 B라는 객체가 존재할 때 구현 클래스 계층이라고 말합니다.

2. Bridge 패턴의 등장인물

Abstraction(추상화)의 역할
1. 기능 클래스 계층의 상위 클래스입니다. 기본 기능만 정의되어 있습니다.
RefinedAbstaction(개선된 추상화)의 역할
1. 기능 클래스 계층의 하위 클래스입니다. 기능을 추가한 역할입니다.
Implementor(구현자)의 역할
1. 구현 클래스 계층의 상의 클래스입니다. 인터페이스(API)를 규정합니다.
Concrete Implementor(구체적인 구현자)의 역할
1. 구현 클래스 계층의 하위 클래스입니다. 인터페이스를(API)를 정의합니다.

Bridge 패턴의 클래스 다이어그램

3. 예제

예제를 통해 내용을 구체화하겠습니다.

3-1. 예제 클래스 다이어그램

3-2. Display 클래스

기능 클래스 계층의 상위 클래스로써 , 구현 클래스 계층의 상위클래스를 인스턴스로 가지며, 공통된 기능을 정의합니다.

public class Display  {
    private DisplayImpl impl;

    public Display(DisplayImpl impl) {
        this.impl = impl;
    }

    public void open() {
        impl.rawOpen();
    }

    public void print() {
        impl.rawPrint();
    }

    public void close() {
        impl.rawClose();
    }

    public final void display() {
        open();
        print();
        close();
    }
}

3-3. CountDisplay 클래스

기능 클래스 계층의 하위 클래스로써 기능을 확장하는 역할을 합니다. 말 그대로 구현은 관계없이 기능만 추가하는 역할을 합니다.

public class CountDisplay extends Display {

    public CountDisplay(DisplayImpl impl) {
        super(impl);
    }

    public void multiDisplay(int times) {
        open();
        for(int i = 0; i < times; i ++) {
            print();
        }
        close();
    }
}

3-4. DisplayImpl 인터페이스

구현 클래스 계층의 최상위에 해당하며 구현할 메소드를 정의한 인터페이스(API)입니다.

public interface DisplayImpl {
    public void rawOpen();
    public void rawPrint();
    public void rawClose();
}

3-5. StringDisplayImpl 클래스

구현 클래스의 하위에 해당하며, 상위 인터페이스 또는 클래스의 메소드를 규현합니다.

public class StringDisplayImpl implements DisplayImpl {

    private String string;
    private int width;

    public StringDisplayImpl(String string) {
        this.string = string;
        this.width = string.getBytes().length;
    }

    @Override
    public void rawClose() {
        printLine();
    }

    @Override
    public void rawOpen() {
        printLine();
    }

    @Override
    public void rawPrint() {
        System.out.println("|" + string + "|");
    }

    private void printLine() {
        System.out.print("+");
        for (int i = 0; i < width; i++) {
            System.out.print("-");
        }
        System.out.println("+");
    }
}

3-6. Main 클래스

public class Main {
    public static void main(String[] args) {
        Display d1 = new Display(new StringDisplayImpl("Hello, Lee"));
        Display d2 = new CountDisplay(new StringDisplayImpl("Hello, world"));

        CountDisplay d3 = new CountDisplay(new StringDisplayImpl("Hello, Universe"));

        d1.display();
        d2.display();
        d3.display();
        d3.multiDisplay(5);
    }
}

실행 결과

+----------+
|Hello, Lee|
+----------+
+------------+
|Hello, world|
+------------+
+---------------+
|Hello, Universe|
+---------------+
+---------------+
|Hello, Universe|
|Hello, Universe|
|Hello, Universe|
|Hello, Universe|
|Hello, Universe|
+---------------+

그렇다면 왜 사용할까?

두 계층을 분리함으로써 확장이 편리해집니다. 서로 변경이 되어도 클라이은트 쪽에는 영향이 없습니다.
여러 플랫폼에서 사용해야 할 그래픽스 및 윈도우처리 시스템에서 유용하게 쓰입니다.

단 단점으로 패턴을 매우 응집력있는 클래스에 적용하면 코드가 더 복잡해질 수 있습니다.

4. 관련 패턴

Template Method 패턴 : 해당 패턴에서 구현의 클래스 계층을 이용합니다. link
Abstract Factory 패턴 : Bridge 패턴의 ConcreteImplementor 역할을 해당 패턴이 이용되는 경우가 있습니다. link
Adapter 패턴 : 해당 패턴은 Bridge와 비슷하지만, 인터페이스(API)가 다른 클래스를 결합시키는 패턴입니다. link

5. 비교하기

Adapter 패턴 : 서로 다른 인터페이스(API)를 연결해줍니다. link
Bridge 패턴 : 구현 계층과 기능(추상) 계층을 연결해줍니다. link

[디자인패턴/Design Pattern] Proxy Pattern / 프록시 패턴

효기로그 — Thu, 19 Dec 2019 14:37:59 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문],[Head First Design Pattern]의 내용을 참고해서 정리한 내용입니다.
잘못된 부분은 댓글로 피드백 부탁드립니다.

1. Proxy 패턴이란?

어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴

2. Proxy 패턴의 등장인물

Subject(주체)의 역할
1. Proxy 역할과 RealSubject 역할을 동일시하기 위한 인터페이스(API)를 결정합니다. 이 덕분에 클라이언트는 둘의 역할 차이를 몰라도 됩니다.
Proxy(대리인)의 역할
1. Client의 요구를 할 수 있을 만큼 처리하고, 필요할 경우 RealSubject에게 처리를 맡깁니다.
RealSubject(실제의 주체)의 역할
1. Proxy에서 요청이 들어왔을때 요청에 대한 응답을 합니다.

3. 예제

3-1. 예제 클래스 다이어그램

3-2. PritableSubject 인터페이스

public interface PrintableSubject {
    void setPrinterName(String name);
    String getPrinterName();
    void print(String string);
}

역할 설명에서 언급했던것처럼 Proxy와 RealSubject역할의 인터페이스(API)를 정의해줍니다.

3-3. PrinterRealSubject 클래스

public class PrinterRealSubject implements PrintableSubject {
    private String name;

    public PrinterRealSubject(String name) {
        this.name = name;
        heavyJob("PrinterRealSubject[" + name + "] 인스턴스 생성중..");
    }

    private void heavyJob(String string) {
        // TODO Auto-generated method stub
        System.out.println(string);
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        System.out.println("생성 완료...");
    }

    public void setPrinterName(String name) {
        this.name = name;
    }

    public String getPrinterName() {
        return name;
    }

    public void print(String string) {
        System.out.println(string);
    }
}

인터페이스를 구현하기 위해 setPrinterName(), getPrinterName(), print() 를 재정의해주고, 객체의 인스턴스 생성의 비용을 무겁게 하기 위해 heavyJob() 이란 메소드를 통해 3초를 지연시킵니다.

3-4. PrinterProxy 클래스

public class PrinterProxy implements PrintableSubject {

    private String name;
    private PrinterRealSubject real;

    public PrinterProxy(String name) {
        this.name = name;
    }

    @Override
    public synchronized void setPrinterName(String name) {
        if (real != null) {
            real.setPrinterName(name);
        }
        this.name = name;

    }

    @Override
    public String getPrinterName() {
        return name;
    }

    @Override
    public synchronized void print(String string) {
        realize();
        real.print(string);
    }

    private synchronized void realize() {
        if (real == null) {
            real = new PrinterRealSubject(name);
        }
    }

}

대리인으로써 처리가 가능한 부분은 객체가 맡아서 처리를 해줍니다. ex ) getPrinterName()
그리고 실제 RealJubject가 필요한 시점에 해당 객체에게 요청을 위임합니다.

3-5. Main 클래스

public class Main {
    public static void main(String[] args) {
        PrintableSubject p = new PrinterProxy("Simple");

        // 프록시가 실행 됨
        System.out.println(p.getPrinterName());

        // realSubject가 실행 
        p.print("프린트 요청");
    }
}

실행 결과

Simple
PrinterRealSubject[Simple] 인스턴스 생성중..
생성 완료...
프린트 요청

왜 사용할까 ?

시작하기에 앞서 Proxy Pattern의 정의를 아래와 같이 설명했습니다.

어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴

그런데 예제만 보고는 왜? 라는 생각이 드실 수 있습니다.

로직에 많은 비용이 필요하면 처음부터 Printer 클래스에서 분리해서 사용하면 되는거 아니야?

라는 의문에는 디자인의 원칙에 의해서 객체들의 역할을 분리해서 개별적으로 수정이 가능하게 하기 위함입니다. 즉 유지보수가 용이하고 클라이언트 입장에서는 지연이 필요할경우 Proxy객체를 사용 필요없이 사용할 경우 PrinterRealSubject를 사용할 수 있습니다.

마지막으로 Proxy Pattern의 정의를 비용이 많이 필요한 경우 역할을 나눠서 지연시킬 수 있는 패턴이라고 정의하지 않고, 본문처럼 포괄적으로 설명한 이유는 무엇일까? Proxy Pattern은 여러 종류 존재하기 때문에 포괄적인 의미만 전달했습니다.

Proxy Pattern의 종류

Virtual Proxy(가상 프록시) : 예제에 해당하는 프록시이며, 인스턴스가 필요한 시점에 생성, 초기화를 실행합니다.
Remote Proxy(원격 프록시 ) : 네트워크가 연결된 상황에서 원격으로 로컬 객체를 원격 객체처럼 사용할 수 있게 해줍니다. Java RMI 등을 사용
Access Proxy(보호 프록시) : RealSubject 기능에 대해서 엑세스 제한을 설정합니다.
Caching Proxy(캐싱 프록시) : 지연이 많이 드는 작업을 임시로 저장, 여러 클라이언트에게 공유합니다.
기타 : 방화벽 프록시, 스마트 레퍼런스 프록시, 동기화 프록시, 복잡도 숨김 프록시, 지연 복사 프록시 등.

4. 관련 패턴

Adapter 패턴 : 연결 해준다는 관점은 같지만 Adapter는 서로 다른 인터페이스를 연결해줍니다. link
Decorator 패턴 : 구현은 비슷하지만 목적이 다릅니다. 새로운 기능을 추가할 때 사용합니다. link

5. 비교하기

객체를 감싸는 패턴이 많은데 구분을 하기 위해 차이점을 정리했습니다,

Decorator 패턴 : 다른 객체를 감싸서 새로운 행동을 추가해줍니다. 기능 확장 link
Facade 패턴 : 여러 객체를 감싸서 인터페이스를 단순화시킵니다. 기능 단순화 link
Adapter 패턴 : 다른 객체를 감싸서 다른 인터페이스를 제공합니다. 호환성 link
Proxy 패턴 : 다른 객체를 감싸서 접근을 제어합니다. 접근제어 link

[디자인패턴/Design Pattern] State Pattern / 스태이트 패턴

효기로그 — Tue, 17 Dec 2019 16:56:37 +0900

1. State 패턴이란?

객체의 내부 상태가 바뀜에 따라서 객체의 행동을 변경할 수 있도록 해주는 패턴

2. State 패턴의 등장인물

State(상태)의 역할
1. 상태가 변할 때마다 다른 동작을 하는 인터페이스(API)를 결정합니다.
ConcreteState(구체적인 상태)의 역할
1. State의 인터페이스(API)를 구체적으로 구현합니다.
Context(상황)의 역할
1. 현재의 상태를 나타내는 ConcreteState 역할을 가집니다. 또한 State 패턴의 이용자에게 필요한 인터페이스(API)를 결정합니다.
  State 패턴의 클래스 다이어그램

3. 예제

어렸을적 동전을 넣고 레버를 돌리면 장난감 캡슐을 주던 기계를 구현한다고 가정해봅니다.
이때, 해당 기계가 가지는 상태를 대충 정리해보면

동전이 있음
동전이 없음
캡슐 출력 중
캡슐 매진

간단하게 위와 같은 상황이 있다고 가정하고 클래스를 작성해봅니다.

3-1. 예제 GumballMachin 클래스

public class GumballMachin {
    enum State {
        HAS_QUARTER, NO_QUARTER, SOLD_OUT, SOLD
    }

    private State state = State.NO_QUARTER;

    // 동전 넣기
    public void insertQuarter() {
        if(state == State.HAS_QUARTER) {
            System.out.println("이미 동전이 있습니다.");
        } else if ( state == State.NO_QUARTER) {
            state = State.HAS_QUARTER;
            System.out.println("동전을 추가하셨습니다.");
        } else if ( state == State.SOLD_OUT) {
            System.out.println("캡슐이 매진되었습니다.");
        } else if ( state == State.SOLD) {
            System.out.println("캡슐이 나오고 있습니다. 잠시만 기다려주세요.");
        }
    }

    // 동전 반환하기
    public void ejectQuarter() {
        if(state == State.HAS_QUARTER) {
            System.out.println("동전이 반환됩니다.");
            state = State.NO_QUARTER;
        } else if ( state == State.NO_QUARTER) {
            System.out.println("동전을 추가해주세요.");
        } else if ( state == State.SOLD_OUT) {
            System.out.println("동전을 넣지 않으셨습니다.");
        } else if ( state == State.SOLD) {
            System.out.println("이미 캡슐을 뽑으셨습니다.");
        }
    }
    // 손잡이 돌리기
    // 캡슐 꺼내기
}

위와 같이 코드를 작성했다고 했을 경우, 행동이 생략된 손잡이 돌리기, 캡슐 꺼내기 외 여러가지가 더 있는 상황이라고 가정해봅니다.
이때 전혀 새로운 상태가 추가 된다면? 새로운 이프문을 추가하고... 검증하고... 생각만해도 머리가 아픕니다.
이럴경우 사용하는 패턴이 State 패턴입니다.

4. 해결방법

해결방법은 상태라는 인터페이스를 구현하고 각각의 상태에서 행동을 정의하는 방식으로 설계를 합니다.

4-1. 클래스 다이어그램

4-2. GumballMachine 클래스

public class GumballMachin {

    State soldState;
    State soldOutState;
    State hasQuarterState;
    State noQuarterState;

    State state = soldOutState;
    int count = 0;

    public GumballMachin(int count) {
        this.soldState = new SoldState(this);
        this.soldOutState = new SoldOutState(this);
        this.hasQuarterState = new HasQuarterstate(this);
        this.noQuarterState = new NoQuarterState(this);
        this.count = count;
        if(count > 0) {
            state = noQuarterState;
        }
    }

    public void insertQuarter() {
        state.insertQuarter();
    }

    // 기타 필요 메소드
}

위와 같이 객체들을 구성으로 가지며, 생성자를 통해 초기화를 합니다. 이때 본인을 매개변수로 넘겨서 해당 State 클래스에서 참조할 수 있도록 합니다.

4-2. State 인터페이스

public interface State {
    public void insertQuarter();
    public void ejectQuarter();
    public void turnCrank();
    public void dispense();
}

공통된 행동을 정의합니다.

4-3. NoQuarterState 클래스

public class NoQuarterState implements State {
    GumballMachin gumballMachine;

    public NoQuarterState(GumballMachin gumballMachine) {
        this.gumballMachine = gumballMachine;
    }

    @Override
    public void dispense() {
        System.out.println("동전을 넣어주세요.");
    }

    @Override
    public void ejectQuarter() {
        System.out.println("동전을 넣어주세요.");
    }

    @Override
    public void insertQuarter() {
        System.out.println("동전을 넣으셨습니다.");

    }

    public void turnCrank() {
        System.out.println("동전을 넣어주세요.");
    }
}

해당 클래스와 같이 각각의 상태에 따라 행동을 정의해줍니다.
다른 HasQuarterstate, SoldOutState, SoldState 도 알맞게 정의해줍니다.

4-4. Main 클래스

public class Main {
    public static void main(String[] args) {

        GumballMachin gumballMachin = new GumballMachin(5);
        // 동전을 넣고 래버 당기기
        gumballMachin.insertQuarter();
        gumballMachin.turnCrank();

        // 동전을 넣고 동전 반환 받기
        gumballMachin.insertQuarter();
        gumballMachin.ejectQuarter();

        // 필요한 로직 작성...
    }
}

왜 사용할까?

클라이언트가 직접 상태를 조작하지 않아도, 객체의 상태를 각 ConcreteState 클래스들이 컨트롤 해주기 때문에 별도의 상태 조작 없이 객체를 사용할 수 있다.

5. 관련 패턴

Singleton 패턴 : ConcreteState 역할은 Singleton 패턴으로 구현되는 경우가 있습니다. link
Flyweight 패턴 : 상태를 표시하는 클래스는 인스턴스를 갖지 않습니다. 따라서 해당 패턴을 사용해서 ConcreteState 역할을 복수의 Context 역할에서 공유할 수 있는 경우가 있습니다.

6. 비교하기

얼핏 보면 클레스 다이어그램이 Strategy 패턴과 차이가 없어 보입니다. 하지만 이 두 패턴은 용도에 있어서 차이가 있습니다.

Strategy 패턴 : 클라이언트가 어떤 전략을 사용할지 지정해줘야 합니다. 즉 사용자가 쉽게 알고리즘 전략을 바꿀 수 있도록 유연성 제공 link
State 패턴 : 상태 객체의 일련의 행동이 캡슐화 되고, 그 객체의 내부 상태에 따라 현재 상태를 나타내는 객체가 바뀌게 되고, 자연스럽게 행동도 변경됩니다. 즉 클라이언트는 객체의 상태에 대해서 아무것도 몰라도 됩니다.

[디자인패턴/Design Pattern] Composite Pattern / 컴포지트 패턴

효기로그 — Tue, 17 Dec 2019 15:06:22 +0900

1. Composite 패턴이란?

개별 객체와 복합 객체를 똑같은 방법으로 취급하는 것, 해당 패턴을 사용하면 객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층 구조로 만들 수 있습니다.

2. Composite 패턴의 등장인물

Leaf(나뭇잎)의 역할
1. '단일객체'을 표시하는 역할을 수행하며, 내부에는 다른 것을 넣을 수 없습니다.
Composite(복합체)의 역할
1. '복합객체'를 나타내는 역할을 하며, Leaf나 Composite 역할을 넣을 수 있습니다.
Component의 역할
1. Leaf, Composite의 역할을 동일시하는 역할이며, 둘의 상위 클래스입니다.

Composite 패턴의 클래스 다이어그램

3. 예제

3-1. MenuComponent 클래스

우선 Component역할인 MenuComponent 클래스입니다.

public abstract class MenuComponent {

    public void add(MenuComponent menuComponent) {
        throw new UnsupportedOperationException();
    }

    // 기타 필요한 메소드 정의

    public void print() {
        throw new UnsupportedOperationException();
    }
}

디자인의 원칙에 의해서 인터페이스로 선언하지 않고 추상 클래스로 선언한 이유는
Leaf, Composite는 역할이 달라서 각 역할에 맞는 기본 메소드를 구현하기 불가능 하기 때문에 예외처리 라는 기본 구현을 제공하기 위해서 추상 클래스를 사용하였습니다.

3-2. MenuItem 클래스

Leaf 역할입니다.

public class MenuItem extends MenuComponent {
    private String name;
    private String description;
    double price;

    // 생성자, 게터 생략

    public void print() {
        System.out.println(" - " + getName() + " : " + getPrice());
        System.out.println("    -- " + getDescription());
    }
}

단일 객체로써 필요한 동작을 하면 역할은 끝입니다.

3-3. Menu 클래스

Composite 역할입니다.

public class Menu extends MenuComponent {
    ArrayList menuComponents = new ArrayList();
    String name;
    String description;

    // 생성자, 게터 생략

    public void print() {
        System.out.println(getName() + ", " + getDescription());
        System.out.println("-----------------------------------------");
        Iterator iterator = menuComponents.iterator();
        while(iterator.hasNext()) {
            MenuComponent menuComponent = 
                    (MenuComponent) iterator.next();
            menuComponent.print();
        }
        System.out.println();
    }
}

Composite 요소는 Compoent 요소를 자식으로 가집니다. 그래서 자식들을 관리하기 위한 print() 메소드를 재정의 합니다.

3-4. Main 클래스

public class Main {
    public static void main(String[] args) {
        MenuComponent pancakeHouseMenu = new Menu ("팬케이크 하우스 메뉴", "런치 메뉴");

        MenuComponent cafeMenu = new Menu ("카페메뉴", "브런치 메뉴");

        MenuComponent dessertMenu = new Menu ("디저트 메뉴", "디저트를 즐겨 보세요!");

        MenuComponent allMenus = new Menu("전체 메뉴" , " 전체 메뉴");

        allMenus.add(pancakeHouseMenu);
        allMenus.add(cafeMenu);
        allMenus.add(dessertMenu);

        pancakeHouseMenu.add(new MenuItem("기본 팬케이크", "고소한 기본 팬 케이크", 4400));
        pancakeHouseMenu.add(new MenuItem("블루베리 팬케이크", "달콤한 블루베리 시럽이 추가된 팬 케이크", 6400));

        // 기타 메뉴 추가 생략

        allMenus.print();
    }
}

전체 트리의 맨 위구조를 가질 allEmnus 에 Composite역할을 하는 { pancakeHouseMenu, cafeMenu, dessertMenu }를 담아주고 각각의 집합체에 Leaf역을 하는 MenuItem을 추가해줍니다.

실행 결과

전체 메뉴,  전체 메뉴
-----------------------------------------
팬케이크 하우스 메뉴, 런치 메뉴
-----------------------------------------
 - 기본 팬케이크 : 4400.0
    -- 고소한 기본 팬 케이크
 - 블루베리 팬케이크 : 6400.0
    -- 달콤한 블루베리 시럽이 추가된 팬 케이크

카페메뉴, 브런치 메뉴
-----------------------------------------
 - 치즈 케이크 : 23000.0
    -- 이달의 인기 치즈 케이크입니다.
 - 초코 쿠키 : 2000.0
    -- 바삭한 초코 쿠키입니다.

디저트 메뉴, 디저트를 즐겨 보세요!
-----------------------------------------
 - 팥빙수 : 4500.0
    -- 여름철 더위를 책임질 오리지널 팥빙수입니다.
 - 우유 : 1500.0
    -- 고소한 소화가 잘되는 우유입니다.

전체 트리 구조의 간략한 모양입니다.

3-5. 왜 사용할까?

위 트리구조 예시에서 처럼 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 전체 - 부분 관계로 정의할 수 있다.
즉 트리 구조로 표현하고 싶은 경우 사용

4. 관련 패턴

Command 패턴 : '매크로 커맨드'를 만들 때 Composite 패턴이 사용됩니다.
Visitor 패턴 : Composite를 순환하면서 처리하는데 사용합니다.
Decorator 패턴 : 장식과 내용물을 동일시합니다. 동일시 한다는 공통점이 있습니다. link

[디자인패턴/Design Pattern] Facade Pattern / 퍼사드 패턴

효기로그 — Mon, 16 Dec 2019 15:58:03 +0900

1. Facade 패턴이란?

어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공합니다. 즉, 서브시스템들을 사용하기 쉽게 통합해주는 역할을 합니다.

2. Facade 패턴의 등장인물

Facade(정면)의 역할
1. 수만은 서브기능들에 대한 '창구'가 됩니다. 높은 레벨에서 단순한 인터페이스(API)를 외부에 제공합니다.
  
  Facade 패턴의 클래스 다이어그램

3. 예제

여러분들이 집에서 영화를 보려고 자동화 시스템을 만들기로 합니다. 이때 준비해야할 목록들을 생각해봅니다.

팝콘 또는 간식 준비
음료 준비
스크린 내리기
엠프 준비
빔프로젝터 가동
기타 등등등..

위 예시와 같이 영화를 보기 위해서 복잡한 서브시스템들을 동작해야 합니다.

public static void main(String[] args) {
        Screen screen = new Screen();
        screen.down();

        new Projector projector = new Projector();
        projector.on();

        // 등등 기타 필요한 서브프로그램 동작
    }

위와 같이 동작한다고 가정했을 경우 영화가 끝나고 각종 서브 시스템들을 종료해야 할 경우, 위와 같은 과정의 반대과정을 또 수행해야 할까요? 서브 시스템에 수정이 생기면 클라이언트는 또 다른 수정이 필요하게 됩니다.
이와 같은 문제에서 Facade 패턴을 사용합니다.

4. 해결방법

위와 같은 문제를 해결하는 방법은 간단합니다. 서브시스템들의 사용을 정의한 인터페이스(API) 클래스를 하나 만들어주고, 클라이언트는 해당 클래스를 통해서 영화를 볼 수 있게 설계하면 됩니다.

4-1. HomeTheaterFacade 클래스 ( API )

public class HomeTheaterFacade {
    DvdPlayer dvd;
    Projector projector;
    Screen screen;
    Amplifier amp;

    public HomeTheaterFacade(DvdPlayer dvd, Projector projector, Screen screen, Amplifier amp) {
        super();
        this.dvd = dvd;
        this.projector = projector;
        this.screen = screen;
        this.amp = amp;
    }

    public void watchMovie(String movie) {
        System.out.println(movie +" 영화를 보기 위한 준비중입니다.");
        screen.down();
        projector.on();
        amp.on();
        dvd.on();
        dvd.play(movie);

    }
}

위와 같이 서브 시스템의 사용을 정의합니다. 만약 추가 기능이 필요하면 메소드를 추가해주면 되고, 수정이 발생할 경우 클라이언트쪽 소스가 아닌 해당 클래스의 수정이 있으면 됩니다.

4-2. Main 클래스

public class Main {
    public static void main(String[] args) {
        HomeTheaterFacade homeTheatherFacade = new HomeTheaterFacade(
                new DvdPlayer(),new Projector(), new Screen(), new Amplifier());

        homeTheatherFacade.watchMovie("The Thirteenth Floor( 13층 )");
    }
}

4-3. 실행 결과

The Thirteenth Floor( 13층 ) 영화를 보기 위한 준비중입니다.
스크린을 내립니다.
프로젝터 실행
엠프 동작
DVD 인식 완료
------The Thirteenth Floor( 13층 ) 내용 -------

4-4 왜 사용할까?

사용 예제와 같이 클라이언트는 복잡한 서비스시템의 동작을 관리하지 않아도 됩니다.
- 즉 단순화된 인터페이스를 통해서 서브시스템을 더 쉽게 사용할 수 있도록 하기 위해 사용
서비시스템에 변경이 있어도 클라이언트의 수정은 필요가 없다.

5. 관련 패턴

Abstract Factory 패턴 : 오브젝트 생성이라는 복잡한 작업을 Facade 패턴으로 간주할 수 있습니다. link
Singleton 패턴 : Facade는 싱글톤으로 만들어지는 경우가 있습니다. link
Mediator패턴 :Facade는 단방향이지만, 해당 패턴은 양방향으로, 중개자역할을 합니다.

6. 비교하기

디자인 패턴을 배우다 보니까 Adapter , Decorator, Facade 가 얼핏 보면 비슷하다고 느낌이 들어서 차이점을 정리합니다.

Adapter : 관계가 없는 인터페이스(API)를 연결할 때 사용, 호환성 link
Decorator : 인터페이스(API)를 바꾸지 않고 기능을 추가. 확장성 link
Facade : 인터페이스(API)를 간편하게 사용. 간편함 link

[자바/알고리즘] 프로그래머스 주식가격

효기로그 — Mon, 16 Dec 2019 13:32:44 +0900

문제 설명

초 단위로 기록된 주식가격이 담긴 배열 prices가 매개변수로 주어질 때, 가격이 떨어지지 않은 기간은 몇 초인지를 return 하도록 sulution 함수를 완성하세요.

제한사항

prices의 각 가격은 1 이상 10,000 이하인 자연수입니다.
prices의 길이는 2 이상 100,000 이하입니다.

입출력 예

prices	return
[1, 2, 3, 2, 3]	[4, 3, 1, 1, 0]

입출력 예 설명

1초 시점의 \1은 끝까지 가격이 떨어지지 않았습니다,
2초 시점의 \2은 끝까지 가격이 떨어지지 않았습니다.
3초 시점의 \3은 1뒤에 가격이 떨어집니다. 따라서 1초간 가격이 떨어지지 않은것으로 봅니다.
4초 시점의 \2은 1초간 가격이 떨어지지 않았습니다,
5초 시점의 \3은 0초간 가격이 떨어지지 않았습니다,

나의 풀이

class Solution {
    public int[] solution(int[] prices) {
        int[] answer = new int[prices.length];

        for (int i = 0; i < answer.length; i++) {
            int sec = 0;
            int su = prices[i];
            for (int j = i+1; j < prices.length; j++) {
                sec ++;
                if(su > prices[j]) {
                    break;
                }
            }
            answer[i] = sec;
        }
        return answer;
    }
}

풀이 설명

각 시점 즉 prices[]의 인덱스마다 가격이 떨어지는 시점을 기억하기 위해서 su라는 변수에 해당 시점의 가격을, sec라고해서 유지한 시간을 기록하기 위한 변수를 선언했습니다.
그 후, 가격이 떨어지는지 배교해가면서 break 문으로 반복문을 컨트롤하면서 값을 리턴해줍니다.

[자바/알고리즘] 프로그래머스 문자열 내림차순으로 배치하기

효기로그 — Fri, 13 Dec 2019 16:58:58 +0900

문제 설명

문자열 s에 나타나는 문자를 큰것부터 작은 순으로 정렬해 새로운 문자열을 리턴하는 함수, solution을 완성해주세요.
s는 영문 대소문자로만 구성되어 있으며, 대문자는 소문자보다 작은 것으로 간주합니다.

제한 사항

str은 길이 1 이상인 문자열입니다.

입출력 예

S	return
"Zbcdefg"	"gfedcbZ"

람다를 활용한 풀이

최근 람다식을 공부하고 있어서 시간날 때 기존의 풀이를 람다로 변경해보는 연습을 진행중입니다.
기존 아래의 코드를 람다식으로 풀어본 결과입니다.

class Solution {
  public String solution(String s) {

      return Stream.of(s.split(""))
                .sorted(Collections.reverseOrder())
                .collect(Collectors.joining());
  }
}

나의 풀이

class Solution {
  public String solution(String s) {

      char[] cArr = s.toCharArray();

      for (int i = 1; i < cArr.length; i++) {    
            for (int j = 0; j < cArr.length; j++) {
                if(cArr[i]>cArr[j]) {
                    char temp = cArr[j];
                    cArr[j] = cArr[i];
                    cArr[i] = temp;
                    i--;
                    break;
                }
            }
        }
      return new String(cArr);
  }
}

풀이 설명

기본적으로 다른사람들은 Arrays.sort() 를 사용해 정렬 후, 리버스 하는 방식으로 풀이를 접근했습니다.
저는 이와 비슷한 문제에서 자주 사용했기 때문에 정렬 자체를 구현해보는게 목적이였습니다.

[디자인패턴/Design Pattern] Decorator Pattern / 데코레이터 패턴

효기로그 — Thu, 12 Dec 2019 14:03:46 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문],[Head First Design Pattern]의 내용을 참고해서 정리한 내용입니다. 잘못된 부분은 댓글로 피드백 주시면 감사하겠습니다.

1. Docorator 패턴이란?

객체에 추가적인 요건을 동적으로 첨가할때 사용하는 방식으로, 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공합니다.

2. Decorator 패턴의 등장인물

Component
1. 기능을 추가할 때 핵심이 되는 역할로, 해당 기능의 인터페이스(API)만을 결정합니다.
ConcreteCompoent
1. Component를 실제로 구현하는 역할입니다.
Decorator(장식자)
1. Component와 동일한 인터페이스(API)를 가지며, 구체적인 장식자의 Component 역할을 합니다.
ConcreteDecorator(구체적인 장식자)
1. Decorator를 시렞로 구현하는 역할입니다.

2-1. Decorator 패턴의 클래스 다이어그램

3. 예제

여러분이 스타OO과 같은 음료회사의 주문시스템을 만들어야 하는 상황이 생겼다고 가정했을 때, 음료라는 큰 슈퍼클래스를 두고 음료들을 서브클래스로 두어서 구현을 하려고 할 것입니다.
그런데 음료의 갯수가 너무 많아진다면? 또한 휘핑크림 추가나 우유 추가등 첨가물에 따라서 동작이나 가격이 달라진다면? 엄청나게 많은 클래스가 필요할것이고, 휘핑크림의 가격이 변동되면 수정해야 될 클래스들도 상당할 것이다.

3-1. 예제 클래스 다이어그램

이와 같은 상황에 여러분들은 공통되는 부분을 추출하고자 첨가물인 밀크, 휘핑크림등을 슈퍼클래스의 구성으로 가지면 밀크가 들어간 에스프레소, 휘핑크림이 들어간 에스프레소 등을 하나의 에스프레소 클래스로 줄일 수 있지 않을까라는 생각이 들 수도 있습니다.

3-2. 첨가물을 구성으로 가지는 슈퍼 클래스

public abstract class Beverage {
    private Milk milk ;
    private Whip whip;
    // 기타 필요한 필드 및 생성자는 생략

    public void addMilk() { 
        // 우유 추가 동작 구현
    }
    // milk 관련 메소드 게터세터 등등
    // 나머지 메소드도 생략

}

대충 슈퍼클래스가 위와 같은 방식으로 정의되어 있을 때, 첨가물을 구성으로 사용하여 클래스 개수도 줄이는 등 괜찮아 보일 수 있지만 아직도 아래와 같은 문제점이 존재합니다.

3-2 클래스의 문제점

첨가물에 대한 수정이 있을 경우 super 클래스의 수정이 필요 ( 추가, 수정, 삭제 등 )
새로운 클래스가 우유가 들어가면 안되는 경우 서브클래스에서 addMilk() 메소드가 동작 안하도록 추가 구현 필요
우유를 2번 추가하는 동작이 필요하면 doubleAddMilk() 메소드가 필요

등과 같은 여러 문제가 아직 발생합니다. 이렇게 동적으로 객체에 요건을 추가할 상황이 많을 경우 데코레이터 패턴을 사용합니다.

4. Decorator 패턴을 사용한 해결

4-1. 예제에 사용 될 클래스 다이어그램

4-2. BeverageComponent 클래스

Compoent 역할로써 전체의 핵심 역할로 인터페이스(API)를 정의하는 클래스입니다. 여기서 전체 구현하는 클래스들의 '형식'을 정해줍니다. 사실상 좀 더 발전된 디자인의 방식으로는 해당 클래스도 abstract가 아닌 interface로 '형식'만 정의해주는 방식이 가장 이상적이지만
예제에서는 기존에 BeverageComponent라는 추상클래스가 존재할 때 변경방법을 소개하는 방향이여서 추상 클래스를 써야 하는 상황이라면 그냥 추상클래스로 구성하는게 더 나을수도 있습니다. 즉 구현하는 시점에 좀 더 비용이 저렴한 방식을 사용하면 됩니다.

public abstract class BeverageComponent {
    protected String name;

    public String getName() {
        return name;
    }
    public abstract int cost();
}

4-3. CondimentDecorator 클래스

Decorator의 역할로, Compoent역할인 BeverageComponent를 상속받으며, ConcreteDecorator의 Compoent를 역할을 수행합니다.

public abstract class CondimentDecorator extends BeverageComponent {
    public abstract String getName();
}

4-4. Hazelnut 클래스

ConcreteDecorator의 역할로 CondimentDecorator를 상속받아 내용을 정의해줍니다.
핵심은 필드로 BeverageComponent 클래스를 가지며, 확장의 대상이 될 객체를 참조시킵니다.
나머지 Milk, Mocha 도 필요에 따라 정의해주시면 됩니다.

public class Hazelnut extends CondimentDecorator {
    BeverageComponent beverage;

    public Hazelnut(BeverageComponent beverage) {
        this.beverage = beverage;
    }

    @Override
    public String getName() {
        return "헤이즐넛 시럽 추가, " + beverage.getName() ;
    }

    @Override
    public int cost() {
        return 500 + beverage.cost();
    }
}

4-5. Main 클래스

public class Main {
    public static void main(String[] args) {

        BeverageComponent beverage = new Americano();
        System.out.println(beverage.getName() +" 가격 : " + beverage.cost());

        BeverageComponent beverage2 = new Americano();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Hazelnut(beverage2);
        System.out.println(beverage2.getName() +" 가격 : " + beverage2.cost());

    }
}

beverage2를 보시면 생성자를 통해 확장시키고 싶은 객체를 참조시키며 자신으로 감싸는 모습이 보입니다.
이렇게 확장이 필요할 경우 원하는 만큼 객체를 감싸면서 객체를 확장해 갈 수 있는 방식입니다.

4-5 실행결과

아메리카노 가격 : 2000
헤이즐넛 시럽 추가, 모카 추가,  아메리카노 가격 : 3300
우유 추가 , 아메리카노 가격 : 3500

왜 사용할까?

추가 첨가물(휘핑크림)인 Whip 클래스가 추가 된다고 가정했을 때, 그냥 Whip 클래스를 생성해주고, CondimentDecorator 클래스를 상속받아 내용만 정의해주면 기존 코드에 수정없이 클라이언트는 Whip 첨가물을 사용할 수 있게 됩니다.

5. 관련 패턴

Adapter 패턴 : Decorator 패턴은 내용을 변경없이 장식을 추가하는 패턴이고, 해당 패턴은 다른 두개의 인터페이스를 연결해줍니다. link
Strategy 패턴 : 알고리즘 자체를 변경해서 기능을 확장이 아닌 변경합니다. link

6. 비교하기

디자인 패턴을 배우다 보니까 Adapter , Decorator, Facade 가 얼핏 보면 비슷하다고 느낌이 들어서 차이점을 정리합니다.

Adapter : 관계가 없는 인터페이스(API)를 연결할 때 사용, 호환성 link
Decorator : 인터페이스(API)를 바꾸지 않고 기능을 추가. 확장성 link
Facade : 인터페이스(API)를 간편하게 사용. 간편함 link

[디자인패턴/Design Pattern] Observer 패턴 / 관찰자 패턴 / Publish-Subscribe 패턴

효기로그 — Wed, 11 Dec 2019 16:39:16 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문],[Head First Design Pattern] 의 내용을 정리해서 작성한 내용입니다. 잘못된 부분이 있으면 댓글로 알려주시면 감사하겠습니다.

1. Observer 패턴이란?

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 변화를 알려주고 자동으로 내용이 갱신되는 방식으로 일대다의 의존성을 정의합니다.
즉 상태 변화에 따른 처리를 기술할 때 사용합니다. 또한 느슨한 결합을 통해 의존성을 제거해줍니다.

2. Observer 패턴의 등장 인물

Subject(관찰 대상자)의 역할
1. '관찰되는 대상'을 관리하는 요소
ConcreteSubject(구체적인 관찰 대상자)의 역할
1. 구체적으로 Subject를 표현하는 역할이며, 통보하는 클래스
Observer(관찰자)의 역할
1. '상태가 변화됨'을 전달 받는 역할을 합니다.
ContreteObserver(구체적인 관찰자)의 역할
1. Observer를 구체적으로 표현하며, '변화를 통보 받는' 클래스

3. 예제

그렇다면 ConcreteSubject와 ContreteObserver를 바로 연관관계를 맺고 사용하면 되지 왜 Subject와 Observer 인터페이스를 구현하면서 사용하는 것일까 ?

3-1. WeatherDataSubject 클래스

public class WeatherDataSubject {

    // 인스턴스 변수 
    ...

    public void weatherUpdate() {

        float temp = getTemperature(); // 온도 가져오기

        // 변화를 알려주기
        currentWeatherDisplay.update(temp, humidiry,);
        forecastDisplay.update(temp, humidiry,);
    }
}

위와 같이 존재하고 각각 CurrentWeatherDisplay 클래스와, ForecastDisplay 클래스가 있을 때 여러가지 문제점이 발생합니다.

첫째로, 통계를 보고 싶어서 StatisticsDisplay 라는 클래스를 추가하고 싶은 경우, weatherUpdate() 메서드 부분에 수정이 필요합니다.
둘째로, 각 클래스마다 행동이 다를 수 있기 때문에 캡슐화를 해야 합니다.
셋째로, 공통적으로 사용하는 메소드 update()를 인터페이스로 정의합니다.

이렇게 객체 간 의존성이 존재하게 됩니다.

3. 해결법

위와 같은 문제를 해결하기 위해 Observer 패턴을 사용합니다.

각 객체는 언제든지 옵저버로 추가되고 삭제될 수 있어야 합니다.
변화될 수 있는 행동은 구현이 아닌 인터페이스를 사용해야 합니다.

3-1. 예제 클래스 다이어그램

3-2. interface ( Subject, Observer, DisplayElement )

여기서 DisplayElement는 행동을 캡슐화할 목적인 인터페이스로 디자인의 원칙에 따라 디자인하기 위해서 추가된 인터페이스입니다. 가장 핵심은 Subject, Observer 인터페이스입니다.

public interface Subject {
    public void registerObserver(Observer o); // 옵저버 등록
    public void removeObserver(Observer o);      // 옵저버 삭제
    public void notifyObservers();               // 변화를 알려주기 위한 메소드
}

public interface Observer {
    public void update(float temp, float humidity);
}

public interface DisplayElement {
    public void display();
}

Subject : '관찰되는 대상'을 관리하는 요소 인터페이스. Observer를 저장, 삭제, 알려주는 메소드를 선언합니다.
Observer : '상태가 변화됨'을 관리하는 요소 인터페이스. 통보당했을 때 처리할 메소드를 선언합니다.
DisplayElement 인터페이스는 행동을 추상화하기 위한 인터페이스로 화면에 그려줄 display() 메소드를 선언합니다.

3-3. WeatherData 클래스

이제 처음에 3번에서 나온 예제의 문제점을 보였던 WeatherData 클래스입니다. 아래는 옵저버 패턴을 사용한 클래스의 변경 내용입니다.

public class WeatherDataSubject implements Subject {
    private ArrayList<Observer> observers; // 옵저버들을 저장
    private float temperature;                
    private float humidity;

    public WeatherDataSubject() {
        observers = new ArrayList<Observer>(); 
    }

    @Override
    public void registerObserver(Observer o) {
        observers.add(o);
    }

    @Override
    public void removeObserver(Observer o) {
        observers.remove(observers.indexOf(o));
    }

    // 변화된 상태를 알려주는 메소드
    @Override
    public void notifyObservers() {
        for (Observer o : observers) {
            o.update(temperature, humidity);
        }
    }

    // 상태가 변화됨을 감지하는 메소드
    public void measurementsChanged() {
        notifyObservers();
    }

    // 상태를 변화 시키는 메소드
    public void setMeasurments(float temperature, float humidity) {
        this.temperature = temperature;
        this.humidity = humidity;
        measurementsChanged();
    }
}

우선 문제였던 옵저버의 추가 삭제를 쉽게 하기 위해서 observers 라는 List 컬렉션을 필드로 가지고, 생성자를 통해 초기화를 해줍니다.
그리고 Subject 인터페이스의 메소드들을 정의해줍니다. 마지막으로 변경된 정보를 받아들일 메소드들을 차례로 정의해줍니다.

3-4. CurrentWeatherDisplay 클래스

public class CurrentWeatherDisplay implements Observer, DisplayElement {
    private float temperature;
    private float humidity;
    private Subject weatherData;

    public CurrentWeatherDisplay( WeatherDataSubject weatherData) {
        this.weatherData = weatherData;
        weatherData.registerObserver(this);
    }

    @Override
    public void update(float temperature, float humidity) {
        this.temperature = temperature;
        this.humidity = humidity;
        display();
    }

    @Override
    public void display( ) {
        System.out.println("최근 기온은 : " + temperature + " / 습도는 : " + humidity +"% 입니다.");
    }
}

WeatherData 객체로부터 변경 사항을 받기 위해 Observer 인터페이스를 구현합니다. 같은 Subject를 쓰기위해 생성자를 통해 weatherData를 전달받고, 필드의 객체에 참조시킵니다. 그리고 registerObserver(Observer) 메소드를 호출해 해당 클래스를 List에 등록시킵니다. 이 부분은 필요에 따라 메소드로 분리하셔도 됩니다.
update() 메소드를 재정의합니다. 그리고 display()메소드를 호출시켜 줍니다. 마찬가지로 재정의해줍니다.

3-5 Main 클래스

public class Main {
    public static void main(String[] args) {
        WeatherDataSubject weatherData = new WeatherDataSubject();

        CurrentWeatherDisplay cwd = new CurrentWeatherDisplay(weatherData);
        ForecastDisplay fd = new ForecastDisplay(weatherData);
        //StatisticsDisplay sd = new StatisticsDisplay(weatherData);

        weatherData.setMeasurments(28, 30);
        weatherData.setMeasurments(34, 89);

    }
}

실행 결과

최근 기온은 : 28.0 / 습도는 : 30.0% 입니다.
내일의 예상 기온은 : 30.0 / 에상 습도는 : 35% 입니다.
최근 기온은 : 34.0 / 습도는 : 89.0% 입니다.
내일의 예상 기온은 : 37.0 / 에상 습도는 : 88% 입니다.

람다로 리팩토링

위 예제에서 사용된 Observer 인터페이스는 함수형 인터페이스라고 볼 수 있다. 그렇기에 아래 처럼 사용이 가능

weatherData.registerObserver((temperature, humidity) 
                -> System.out.println("최근 기온은 : " + temperature + " / 습도는 : " + humidity +"% 입니다."));

        weatherData.registerObserver((temperature, humidity) 
                -> System.out.println("내일의 예상 기온은 : " + (temperature + (new Random().nextInt(6))) +" / 에상 습도는 : " + (new Random().nextInt(100)) + "% 입니다." ));

예제에서는 Display라는 행동을 분리해서 인터페이스화 했었지만, 람다에서는 필요한 구현을 넘기기 때문에 해당 Display 인터페이스와 옵저버 구현 클래스 2개가 불필요해진다.

다만 람다가 만능은 아닙니다. 현재는 구현 자체가 간단하지만, 구현의 로직이 복잡하고 어려운 경우는 기존의 방식처럼 클래스와 인터페이스를 통한 구현을 고려해봐야합니다. 상황에 맞게 사용하시면 되겠습니다.

사용 이유

실행결과와 같이 Clilet는 이제 옵저버를 등록만하고, 변경만 해주면 알아서 변화된 상태를 감지하고 동작을 합니다. ( 예제에서는 display()와 같이 )

문제점이였던 직접적인 참조가 해결되어서 언제든 Obverser을 추가하고 삭제가 가능하다. ( 느슨한 결합 )
전혀 새로운 클래스 예를들어 StatisticsDisplay 클래스가 추가 되어도 Observer 인터페이스를 구현하고, 필요한 로직을 작성해두면, 기존의 코드에는 수정이 없이 옵저버로 사용이 가능하게 됩니다.

4. 관련 패턴

Mediator 패턴 : 패턴의 역할간의 통신에 Observer 패턴을 사용하는 경우가 있습니다. 두 패턴 모두 '상태 변화를 알린다'는 점에서 비슷하지만, 목적이나 시점이 다릅니다. 해당 패턴은 상태변화의 알림 목적이 다른 역할의 조정이라는 목적으로 동작하고, Observer은 상태변화를 알려서 동기화를 이루는 일에 주안점을 두고 있습니다.

[디자인패턴/Design Pattern] Strategy 패턴 / 전략 패턴

효기로그 — Wed, 11 Dec 2019 13:21:47 +0900

관련 내용은[자바 언어로 배우는 디자인 패턴 입문], [Head First Design Pattern] 의 내용을 참고해서 정리한 내용입니다. 잘못된 부분은 댓글로 지적해주시면 감사하겠습니다.

1. Strategy 패턴이란?

알고리즘군을 정의하고 각각을 켑슐화하여 교환해서 사용할 수 있도록 만드는 방식, Strategy 패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.
즉 알고리즘의 인터페이스(API) 부분만 규정해서 변경해서 사용할 수 있도록 하는 것

2. Strategy 패턴의 등장 인물

Strategy(전략)
1. 전략을 이용하기 위한 인터페이스(API)를 결정합니다.
ConcreteStrategy(구체적인 전략)
1. Strategy를 실제로 구현하는 역할
Context(문맥)
1. Strategy의 인터페이스(API)를 호출해서 이용하는 역할

2-1. Strategy 패턴의 클래스 다이어그램

3. 예제

예제를 통해서 내용을 구체화해보겠습니다.
우선 Duck라는 부모 클래스와 하위 클래스로 MallardDuck, RedheadDuck가 존재한다고 가정합니다.
이때 우리는 객체지향적인 특성을 사용하기 위해 상속과, 추상화를 통해 공통된 부분을 부모 클래스에 정의하고 공통되지 않는 부분을 자식 클래스에서 정의하려고 할 것입니다.

3-1. 예제에 사용될 클래스 다이어그램

3-2. Duck 클래스 ( 부모 클래스 )

public abstract class Duck {

    public void swim() {
        System.out.println("오리가 수영을 합니다.");
    }

    public void quack() {
        System.out.println("꽥꽥 웁니다.");
    }

    public abstract void display();
}

3-3. 자식클래스 ( MallardDuck, RedheadDuck, DecoyDuck )

public class MallardDuck extends Duck  {

    @Override
    public void display() {
        // TODO Auto-generated method stub
        System.out.println("청둥오리입니다.");
    }

}

public class RedheadDuck extends Duck{

    @Override
    public void display() {
        System.out.println("붉은 머리 오리입니다.");
    }
}

이런 식으로 우리는 객체지향적으로 객체를 설계할 것입니다. 그런데 추가로 짖지도 않고, 날지도 못하는 가짜 오리인 DecoyDuck가 추가가 된다고 하면? 아래와 같이 정의해야 할 것입니다.

3-4. DecoyDuck

public class DecoyDuck extends Duck{

    @Override
    public void display() {
        System.out.println("장난감 오리입니다.");
    }

    @Override
    public void quack() {
        System.out.println("장난감이 삐용삐용 하고 소리를 냅니다.");
    }
}

나아가 갑자기 오리가 날아가는 기능을 추가해달라고 했습니다. 그렇다면 여러분은 공통기능이라고 생각해 Duck 클래스에
public void fly() { System.out.println("오리가 날아갑니다"); } 라는 메소드를 추가했다고 하면 우리는 가짜 오리인 DecoyDuck에도 추가로 오버라이딩을 해줘야 하는 일이 발생합니다. 이와 같이 코드의 한 부분이 바뀜으로써 전체 프로그램에 수정, 부작용이 발생하게 됩니다.

4. 해결

4-1. 예제에 사용될 클래스 다이어그램

위와 같은 문제로 인해 날기와, 짖기의 행동 자체를 구현이 아닌 inteface(API)로 정의해 사용하는 방식을 사용합니다.

4-2. fly() 관련 전략 생성

public interface FlyStrategy {
    public void fly();
}

public class FlyWithWingStrategy implements FlyStrategy {
    @Override
    public void fly() {
        System.out.println("오리가 날아가고 있습니다.");
    }
}

public class FlyNoWayStategy implements FlyStrategy {
    @Override
    public void fly() {
        System.out.println("이 오리는 날 수 없습니다.");

    }
}

이렇게 행동 자체를 캡슐화해버리는 방식입니다. 마찬가지로 분리시킨 행동인 짖기에 관해서도 추가해주면 됩니다.
그리고 Duck에서 직접적으로 구현했던 fly()부분을 아래와 같이 인터페이스를 comsition (구성)해주고, 해당 인터페이스의 메소드를 사용하는 방식으로 변경합니다.

public abstract class Duck {

    private FlyStrategy flyStrategy;

    public void fly() { flyStrategy.fly();}

    public void swim() { System.out.println("오리가 수영을 합니다.") ; }

    public abstract void display();

    public void setFlyStrategy(FlyStrategy flyStrategy) {
        this.flyStrategy = flyStrategy;
    }
}

여기서 Strategy를 초기화하는 방식으로는 하위 클래스에서 생성자로 컨트롤할 수도 있고 그건 상황에 따라서 사용하시면 될 것 같습니다. 이렇게 사용하면 아래와 같이 사용이 가능하며, 행동을 원할 때 변경할 수 있습니다.

4-3. Main 클래스

public class Main {
    public static void main(String[] args) {
        MallardDuck mallarDuck = new MallardDuck();

        mallarDuck.setFlyStrategy(new FlyWithWingStrategy());
        mallarDuck.fly();

        mallarDuck.setFlyStrategy(new FlyNoWayStategy());
        mallarDuck.fly();
    }
}

4-4. 실행 결과

오리가 날아가고 있습니다.
이 오리는 날 수 없습니다.

4-5. 람다 표현식으로 리팩토링

위 예제에서 전략에 해당하는 FlyStrategy 인터페이스는 선언된 메서드가 1개뿐이기 때문에, 함수형 인터페이스라는 조건에 해당한다. 그래서 람다 표현식으로 4-3의 코드를 아래처럼 변화 가능

    mallarDuck.setFlyStrategy(() -> System.out.println("오리가 날아가고 있습니다."));
    mallarDuck.fly();

    mallarDuck.setFlyStrategy(() -> System.out.println("오리가 날아가고 있습니다."));
    mallarDuck.fly();

다만, 구현해야하는 내용이 지역변수를 참조한다거나, 복잡한 과정, 재사용이 많을 경우는 기존의 방식처럼 클래스를 이용한 방법이 조금 더 나을 수 있다. 전략 패턴의 경우 람다로도 사용이 가능하다고 인지하고, 상황에 맞는 방식을 사용하는 것을 권장합니다. 람다란

왜 사용하는 것일까?

위임이라는 느슨한 연결을 사용하고 있으므로 알고리즘을 용이하게 교환할 수 있습니다.

5. 관련 패턴

Flyweight패턴 : ConcreteStrategy 역할은 해당 패턴을 사용해서 복수의 장소에서 공유 가능
Abstract Factory 패턴 : 알고리즘뿐만 아니라 공장, 부품, 제품을 모두 교체 가능
State 패턴 : 비슷한 방식이지만, 알고리즘이 아닌 '상태' 를 변화하는 방식을 위임

6. 비교하기

디자인 패턴을 배우다 보니까 Strategy , Template Method 가 얼핏 보면 비슷하다고 느낌이 들어서 차이점을 정리합니다.

Strategy : 알고리즘을 구성으로 사용.유연성link
Template Method : 알고리즘을 서브클래스에서 일부 지정할 수 있으면서 재사용이 가능, 하지만 의존성이 크다는 문제가 발생. 재사용link

[자바/알고리즘] 프로그래머스 문자열 내 p와 y의 개수

효기로그 — Tue, 10 Dec 2019 17:20:25 +0900

문제 설명

대문자와 소문자가 섞여있는 문자열 s가 주어집니다. s에 문자 'p'와 'y'의 개수를 비교해 같으면 True, 다르면 False를 return 하는 solution를 완성하세요, 'p', 'y' 모두 하나도 없는 경우는 항상 True를 리턴합니다. 단, 개수를 비교할 때 대문자와 소문자는 구별하지 않습니다.

예를 들어 s가 "pPoooyY"면 true를 return하고 "Pyy"라면 false를 return합니다.

제한사항

문자열 s의 길이 : 50 이하의 자연수
문자열 s는 알파벳으로만 이루어져 있습니다.

입출력 예

S	answer
"pPoooyY"	true
"Pyy"	false

입출력 예 설명

입출력 예 #1
- 'p'의 개수 2개, 'y'의 개수 2개로 같으므로 true를 return 합니다.
입출력 예 #2
- 'p'의 개수 1개, 'y'의 개수 2개로 다르므로 false를 return 합니다.

나의 풀이

class Solution {
    boolean solution(String s) {

        boolean answer = true;

        int cnt1 = 0;
        int cnt2 = 0;

        for(int i = 0; i < s.length(); i++){
            if(Character.toUpperCase(s.charAt(i)) == 'P'){
                cnt1++;
            } else if(Character.toUpperCase(s.charAt(i)) =='Y'){
                cnt2++;
            }
        }

        if(cnt1 != cnt2) {
            answer = false;
        }

        return answer;
    }
}

풀이 설명

아무 값도 없을경우 true를 반환한다는 조건 때문에 answoer을 true로 초기화 해줍니다. 그 후 대소문자 구분을 안하고 값을 비교 하기 위해 Character 래퍼 클래스의 toUpperCase(char) 메소드를 통해 값을 비교 후 카운터 변수를 증가시켜줍니다.
마지막으로 값이 같은지 다른지를 비교해 리턴해줍니다.

[자바/알고리즘] 프로그래머스 두 정수 사이의 합

효기로그 — Tue, 10 Dec 2019 17:11:32 +0900

문제 설명

두 정수 a, b 가 주어졌을 때 a와 b 사이에 속한 모든 정수의 합을 리턴하는 함수, solution을 완성하세요.
예를 들어 a = 3, b = 5 인 경우, 3 + 4 + 5 = 12 이므로 12를 리턴합니다.

제한 조건

a와 b가 같은 경우는 둘 중 아무 수나 리턴하세요.
a와 b는 -10,000,000 이상 10,000,000 이하인 정수입니다.
a와 b의 대소관계는 정해져있지 않습니다.

입출력 예

a	b	return
3	5	12
3	3	3
5	3	12

나의 풀이

class Solution {
  public long solution(int a, int b) {
      long answer = 0;
      int maxNum = (a >= b ? a : b);
      int minNum = (a <=b ? a : b);

      for(int i = minNum ; i <= maxNum; i++){
          answer+= i;
      }
      return answer;
  }
}

풀이 설명

대학교 시절 한참 삼항 연산자를 배울때 풀었던 문제인지라, 삼항 연산자를 통해 최대 값과 최소값을 구해 누계를 하는 방식으로 풀었던거 같다.
다른 사람들은 Math.min(), 함수와 Math.max()함수를 통해 최대값, 최소값을 구하고, 값 누계 부분은 등차수열의 합 공식을 사용해 `(b - a + 1 ) * ( a - b ) / 2; 값을 리턴한 사람들도 많았다.
역시 프로그래밍의 연산 최적화랑 수학은 밀접한 관계가 있는거 같다.

[JAVA/JPA] 연관관계 매핑

효기로그 — Mon, 9 Dec 2019 22:36:21 +0900

테이블과 객체 사이의 간격

TEAM테이블과 MEMBER테이블이 있다고 가정하고, MEMBER테이블은 TEAM을 기본키를 외래키로 가지고 있는 N:1의 관계일 때 기존의 방식으로 객체를 테이블의 데이터 기준으로 작성하면 아래와 같이 사용함 ( Mybaits 등)

public class Member{

    private Long memberId;
    private Long teamId;
    private String memberName;
}

public class Team{ 

    private Long teamId;
    private String teamName;
}

위와 같은 경우 객체끼리의 참조가 끊김, 예를들어 Member에서 member.getTeam()등과 같이 연관 관계가 있는 객체끼리 참조가 불가능함. 이는 객체적인 모델링이 아니다. 이와 같은 이격이 존재하는 이유는 테이블과 객체의 아래와 같은 차이점 때문

테이블은 외래키로 조인( 키값의 데이터 )을 사용해서 연관된 테이블을 찾는다.
객체는 참조를 사용해서 연관된 객체를 찾는다

위와 같은 차이점말고, 테이블은 사실상 기본키 값이든 외래키 값이든 키값을 통해 방향에 상관없이 테이블에서 식별이 가능하다.
그러나 객체의 경우 참조는 단방향일 수 밖에 없다. 예를들어 아래와 같이 객체가 존재할 경우

public class Member{

    private Long memberId;
    private Team team;
    private String memberName;

    public Team getTeam(){ this.team }
}

public class Team{ 

    private Long teamId;
    private String teamName;
}

이제는Member에 단순 키값 Long teamId가 아닌 Team 객체 자체를 넣었기 때문에 Member.getTeam()을 통해서 객체의 참조가 가능하다. 그러나 Team의 경우 Member을 참조할 수 없다. 이것이 일반적인 객체의 참조이고, 객체의 참조는 테이블과 다르게 단방향으로만 가능

그렇다면 객체는 양쪽으로는 참조가 불가능할까? 아니다 각 테이블의 관계를 고려해서 아래와 같이 수정하면 양방향으로도 객체의 참조가 가능해진다. 예제는 Member와 Team이 N:1의 관계라고 가정해본다.

public class Member{

    private Long memberId;
    private Team team;
    private String memberName;

    public Team getTeam(){ return this.team }
}

public class Team{ 

    private Long teamId;
    private String teamName;
    private List<Member> members = ArrayList<>();

    public List<Member> getMembers() { return this.members; } 
}

위와 같이 객체를 설계할 경우, 단방향이 서로 설정이 되며, 이를 양방향이라고 표현한다. 이제 기존의 데이터 지향에서 객체지향으로 설계를 바꿨고, 이제 JPA의 입장에서 생각을 해보자. 만일 Member의 team과 Team의 members 중 어느 값이 변경 되었을 경우 테이블에 영향을 주어야 할까? 이를 설정해주는 것이 이번장의 핵심 연관관계 주인을 지정해주는 것이다.

연관관계 주인

기존의 Member와 Team을 엔티티로 변경하면 아래와 같이 변경할 수 있다.

@Enity
public class Member{

    @Id @GeneratedValue
    @Column( name = "member_id")
    private Long id;

    @ManyToOne
    @JoinColumn( name = "team_id")
    private Team team;
    private String memberName;

    // 기타 필요 메소드 getter(), setter() 등
}

@Enity
public class Team{ 

    @Id @GeneratedValue
    @Column( name = "team_id")
    private Long id;
    private String teamName;

    @OneToMany(mappedBy = "team")
    private List<Member> members = ArrayList<>();

    // 기타 필요 메소드 getter(), setter() 등
}

주목해야 할 어노테이션은 @ManyToOne, @OneToMany, @JoinColumn 이 3가지이다. @ManyToOne, @OneToMany의 경우 이름처럼 테이블의 관계가 1:N인지 N:1인지 N:M인지 등 관계를 표현하는 어노테이션이고, @JoinColumn 어노테이션을 통해 해당 연관관계에서의 주인을 지정해주는 어노테이션이다.

또한 현재 양방향 연관관계이기 때문에 @OneToMany에 mappedBy 속성을 통해서 연관관계의 주인이 아닌 반대 방향이라는 설정을 해줘야 한다.

위와 같이 설정하게 되면 연관관계의 주인을 설정할 경우에만 JPA가 테이블의 값을 변경하고, mappedBy로 설정된 값은 조회만 가능하게 된다.

누구를 연관관계 주인으로?

외래키가 있는 곳을 연관관계 주인으로 지정해라.

사실 객체의 입장에서 누구든 연관관계의 주인이 될 수 있지만, 테이블 기준 외래키가 들어가는 엔티티를 연관관계의 주인으로 설정하기를 권장한다. 아닐 경우 아래와 같은 문제가 발생

team을 연관관계 주인으로 설정할 경우
- 성능상의 이슈, Team을 변경해도 Member의 update 쿼리가 발생한다.
- team을 변경해도 member 테이블을 조작하는 쿼리가 발생해 개발 시 헷갈리게 된다. 즉 직관적이지가 않다.

주의할 점

위와 같이 연관관계 주인을 설정하고, mappedBy 속성을 통해 양방향 연관관계를 설정할 수 있게 되었다.
그렇지만 양방향 연관관계의 경우 아래와 같은 주의점이 발생한다.

toString(), lombok 사용시 무한 루프에 빠지게 된다. 재정의가 필요할 경우 양방향 연관관계를 고려해서 재정의 할 것
JSON 라이브러리를 통해 생성시에도 무한루프에 빠진다. 그래서 컨트롤러에서 entity를 반환하지 말고 DTO를 사용해라

비지니스 로직상 add할때 내가 있는지 체크 후 빼고, 추가 이런 로직이 필요하면 추가로 changeTeam에 설정..

실제는 단방향으로 모든 엔티티를 설계하고 필요에 의해서만 양방향을 고려해라.. 추가로 수정해도 기존 로직에 영향이 없음.. 그러나 JPQL에서 역방향으로 탐색할 일이 많기 때문에

가장 많이 하는 실수

연관관계 주인이 아닌곳은 조회만 가능한 점을 잘 생각하고 아래와 같은 로직이 있을 때 어떤 문제가 발생할까?

Team team = new Team();
em.persist(team);

Member member = new Member();

// 주인이 아닌 역방향만 연관관계 설정
team.getMembers().add(member);

em.persist(member);

위와 같이 작성시 mappedBy로 설정된 읽기전용 필드에만 값을 설정 시 MEMBER 테이블에 TEAM의 키 값이 null로 등록되는 현상이 발생, 그렇기 때문에 아래와 같이 수정

Team team = new Team();
em.persist(team);

Member member = new Member();
member.setTeam(team); // !!! 중요 연관관계 주인에 값을 넣어야함 !!!

// team.getMembers().add(member); 없어도 되지만 둘다 설정하는게 좋다.

em.persist(member);

team.getMember()의 경우 사실상 값을 설정해주지 않아도, JPA가 알아서 지연로딩 기법을 사용해 값을 참조하는 순간 알아서 값이 불러온다. 그치만 이와 같이 사용하면 JPA 메커니즘에 의해 오류가 발생 했을 때 값이 테이블과 동일하지 않는 문제가 발생할 수 있기 때문에 양쪽에 다 넣어주는게 유리하다. 또한 테스트 케이스 작성 시 한쪽으로만 데이터가 있는 경우가 발생하기 때문에 둘다 값을 넣어주는걸 추천

JPA 메커니즘에 의한 오류

Team team = new Team();
em.persist(team);

Member member = new Member();
member.setTeam(team); 

em.persist(member);

Team findTeam = em.find(Team.class, team.getId()); // 1차 캐쉬
List<Member> member = findTeam.getMembers();

위와 같이 동작할때 JPA 메커니즘에 의해 em.persist(team)로 등록된 엔티티는 DB에 저장되는게 아닌, 영속 컨텍스트에 저장되기 때문에 당연히 em.find(Team.class, team.getId()를 통해 불러와도 당연히 DB가 아닌 영속 컨텍스트에서 값일 받아옴.
그럼 해당 객체는 team.getMembers().add(member)를 실행하지 않았기 때문에 당연히 null을 반환 em.find()도 같은 객체를 반환하기 때문에 null 문제가 발생 그렇기 때문에 양쪽에 넣어주는게 좋다.

위와 같은 방법이 아니면 연관관계 편의 메소드를 만들것을 고려해라

// Member Entity
public void change(Team team) {
    this.team = team;
    team.getMembers().add(this);
}

또는 Team 엔티티에 설정해도 상관은 없다. 단 둘중 한곳에만 설정할 것!
또한 List를 사용하기 때문에 로직에 따라 기존의 List에 값이 있으면 찾아서 제거하고, 추가하기 등 필요한 로직은 비니니스 로직에 따라 추가해줘야 하는 경우도 생긴다.

정리

객체와 테이블의 차이점 이해
연관관계 설정 ( 연관관계 주인 파악하기 )
- 외래키를 가진 테이블의 엔티티를 연관관계 주인으로
- 연관관계에서 데이터 조작시 JPA 메커니즘을 이해하고 조작하기 ( 주인만 테이블을 조작 )
toString, lombok, JSON 사용시 무한참조 주의
엔티티는 단방향으로 전부 설계, 필요 시 양방향을 추가할 것 그래도 기존의 테이블에 수정이 없기 때문에 필요시에 추가해도 충분하다.

[JAVA/JPA] Entity Mapping 방법

효기로그 — Mon, 9 Dec 2019 15:42:07 +0900

해당 내용은 인프런의 자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한 의 내용을 기반으로 정리해서 작성한 글입니다.
자세한 내용은 해당 강의 또는 책을 구매하셔서 알아보시는걸 추천합니다.

사용 어노테이션

객체와 테이블 매핑 : @Entity , @Table
필드와 컬럼 매핑 : @Column, @Enumerated, @Temporal, @Lob, @Treansient
기본 키 패킹 : @Id
연관관계 매핑 : @ManyToOne, @JoinColumn

객체와 테이블 매핑

@Entity

정의 : JPA가 관리하는 객체라고 선언하는 어노테이션

기본 생성자 ( public, protected ) 가 필수로 있어야 ( 리플렉션이나 여러 기술을 사용할 때 필요 )
final, enum, interface, inner 클래스는 사용 불가능
필드에도 final 키워드 사용 불가능

속성

name라는 속성이 사용가능하며. Default로 클래스 이름으로 지정, 다른 패키지내 같은 클래스이름이 있을 경우 둘을 구분하기 위해 사용한다.

import javax.persistence.Entity;
@Entity( name = "Member" )
public class Member {
    public Member() { }
}

@Table

정의 : `Entity`와 매핑될 DB 테이블에 대한 설정

속성

속성	기능	기본값
name	매핑할 테이블 이름	Entity 의 name
catalog	데이터베이스 catalog 매핑
schema	데이터베이스 schema 매핑
uniqueConstraints(DDL)	DDL 생성 시에 유니크 제약 조건 생성

필드와 컬럼 매핑

어노테이션	설명
@Column	컬럼과 매핑
@Temporal	날짜 타입 컬럼과 매핑
@Enumerated	enum 타입과 컬럼 매핑
@Lob	BLOB, CLOB 매핑
@Transient	필드와 컬럼 매핑 제외

@Column

속성

name : 테이블에 매칭시킬 컬럼 이름 ( default : 필드명 )
insertable, updateable : 등록, 변경 여부 ( default : true )
nullable : null 값의 허용 여부, false로 설정시 DDL 생성 시에 not null 제약 조건이 자동 생성
unique : @Table의 unique 속성과 같지만 컬럼에도 선언 가능
- 단 실무에서는 Unique 제약조건명이 자동으로 생성되기 때문에 사용을 안함
columnDefinition : 데이터베이스에 컬럼 정보를 직접 생성
length : 문자 컬럼의 길이 제약조건, String 타입에서만 사용가능 (default : 255 )
precision,scale : BigDecimal 타입이나 BigInteger에서 사용, double, float불가, 큰숫자나 정밀한 소수점 계산시 사용
- percision : 소수점을 포함한 전체 자릿수
- scale : 소수의 자릿수

public class Member {
    @Column( name ="MEM_NAME", insertable = true, nullable = false
             ,columnDefinition = "varchar2(200) default 'NONE'", length = 255)
    private String name;
    @Column(percision = 19 )
    private BigDecimal age;
}

@Enumerated

Enum 타입을 매핑할 때 사용 속성으로는 ORDINAL 과 STRING를 사용하지만, STRING만 사용할 것 enum 순서에 변화가 생겼을 때, 순서로 저장할 경우 데이터 불일치 발생
- ORDINAL : enum 순서를 저장
- STRING : enum 이름을 저장

@Temporal

정의 : 날짜 타입 Date, Calendar 을 매핑, LocalDate, LocalDateTime을 사용할 경우 생략 가능

속성

TemporalType.DATE : 날짜, DB의 date 타입과 매핑
TemporalType.TIME : 시간, DB의 time 타입과 매핑
TemporalType.TIMESTAMP : 날짜와 시간, DB의 timestamp와 매핑

public class Member {
   @Temporal(TemporalType.TIMESTAMP)
   private Date;

   private LocalDate localDate;
   pirvate LocalDateTime localDateTime;
}

@Lob

DB의 BLOB, CLOB 와 매핑, 지정할 수 있는 속성이 없으며 문자타입이면 CLOB, 나머지는 BLOB로 자동 매핑

@Transient

필드에서 매핑시 제외시키고 싶은 필드에 선언, 메모라상에서만 쓰고 싶은 경우

기본키 매핑

해당 필드를 DB에 사용할 기본키로 선언시 사용, 직접 할당시 @Id만 선언해주면 되지만, 보통 sequence나 autoincrement 등으로 자동 관리하는 경우가 많은데 그럴 경우 @GeneratedValue를 같이 사용해줘야 한다.

@GeneratedValue의 속성

IDENTITY : DB에 위임, autoincrement ( mySQL )
SEQUECNE : 데이터베이스 시퀀스 sequence 사용 , ORACLE , 추가로 @SequenceGenerator 필요public class Member {}
@Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "MEMBER_SEQ_GENERATOR") private Long id; // 값을 주면 안된다.
@Entity @SequenceGenerator( name = "MEMBER_SEQ_GENERATOR" // sequenceGenerator 이름 지정 squenceName = "MEMBER_SEQ" // 매핑할 시퀀스 이름 initialValue = 1, allocationSize = 1 ) // 시작하는 숫자, 증가값 기본으로 50
TABLE : 키 테이블 사용, 모든 DB에서 사용 가능하지만, 성능 이슈 발생
AUTO : 방언에 따라 자동 지정, 기본 값

기본키 전략 strategy 의 특징

IDENTITY 전략의 특징
- 키값이 자동으로 생성되기 때문에 영속성 컨텍스트는 해당 Entity의 키값을 모른다. ( 영속컨테이너 메커니즘에 의해 ) 그렇기 때문에 commit()나 flush()시점이아닌, persist() 시점에 insert가 발생하고 return 으로 키 값을 받아오기 때문에 별도의 select문은 없음, ( JDBC를 이용 )
SEQUENCE 전략의 특징
- IDENTITY전략과 마찬가지로 DB에 들어가야 키 값을 알 수 있음, 마찬가지로 persist()시점에 동작하며. SEQUENCE.nextVal() 호출로 키 값을 가져오며, insert는 기존의 메커니즘과 같이 commit(), flush()에 동작, 그래서 allocationSize가 default로 50으로 잡혀 있는것!, 불필요하게 DB에 접근해서 sequence값을 가져오지 않고, 버퍼 기능도 사용가능하고, 동시성도 제어 가능

데이터베이스 스키마 자동 생성

객체를 Entity로 매핑을 설정해놓으면 컴파일 단계에서 자동으로 DB에 테이블 생성 ( DDL ) 문을 동작, 개발 환경에서만 사용할 것을 권장

옵션	설명
create	기존테이블 삭제 후 다시 생성
create-drop	create와 같고 종료 시점에 drop
update	변경된 부분만 반영
validate	엔티티와 테이블 정상 매핑 확인
none	사용 x

[JAVA/JPA] 영속성 컨텍스트 EntityManage JPA 동작 방식

효기로그 — Sat, 7 Dec 2019 02:48:46 +0900

해당 내용은 인프런의 자바 ORM 표준 JPA 프로그래밍 - 기본편 , 김영한 의 내용을 기반으로 정리해서 작성한 글입니다.
자세한 내용은 해당 강의 또는 책을 구매하셔서 알아보시는걸 추천합니다.

해당 글을 읽기전 JPA 기본편 을 먼저 보시는걸 추천합니다.

[JAVA/JPA] JPA 와 ORM 기본 개념 Hibernate ORM

해당 내용은 인프런의 자바 ORM 표준 JPA 프로그래밍-기본편 - 김영한 의 내용을 기반으로 정리해서 작성한 글입니다. 자세한 내용은 해당 강의 또는 책을 구매하셔서 자세히 알아보시는걸 추천합니다. ORM 이란?..

lee1535.tistory.com

EntityManagerFactory와 EntityManager

어플리케이션은 단 하나의 EntityManagerFactory를 가져야함. 즉 어플리케이션이 실행하면 생성하고 종료하면 소멸
EntityManager은 하나의 Thread(Transaction)가 생성될 때마다 EntityManagerFactory가 생성해준다.
EntityManager은 실제 DB 사용을 담당

영속성 컨텍스트 ?

논리적인 개념, 눈에 보이지 않음
EntityManager.persist(Entity)를 사용하면 DB에 저장하는게 아닌 영속성 컨텍스트에 저장

엔티티의 생명주기

비영속 : 객체가 영속성 컨텍스트와 관련이 없는 상태
아래와 같이 EntityManger을 통해서 영속성 컨텍스트에 접근하지 않은 상태
```
public void process(){
  Member mbmer = new Member();
}
```
영속 : 객체에 영속성 컨텍스트에 관리되고 있는 상태
아래와 같이 EntityManger을 영속성 컨텍스트에 저장시킨 상태
```
public void process(){
  Member mbmer = new Member();
  entityManager.persist(member);
}
```
준영속 : 영속 컨텍스트에 저장되어 있다가 분리된 상태
아래와 같이 EntityManger을 영속성 컨텍스트에서 객체를 분리시킨 상태
```
public void process(){
  Member mbmer = new Member();
  entityManager.detach(member);
}
```
삭제 : 삭제된 상태
아래와 같이 EntityManger을 영속성 컨텍스트에서 객체를 완전히 삭제시킨 상태
```
public void process(){
  Member mbmer = new Member();
  entityManager.remove(member);
}
```

영속성 컨텍스트 사용 이유

왜 DB에 바로 저장하지 않고 중간 단계인 영속성 컨텍스트라를 통해서 객체를 저장할까?
아래와 같은 이점이 존재

이점

1차 캐시
실제 EntityManager.persist(Entity)를 통해 객체를 저장하면 영속 컨텍스트에 저장만 시킨다
그럼 언제 DB에 접근을 할까? 강조했던 commit시점에 영속 컨텍스트가 1차 캐쉬에 있는 내용을 한번에 DB에 저장시킨다.
아래와 같은 상황에서 DB 접근이 몇번 생기는지 확인해보자
```
public void process(){
   Member member = new Member();
 member.setId(100L);
 entityManager.persist(member);

 Member selectMember = entityManager.find(Member.class, 100L );
}
```
psersist()를 호출 했으니까 insert를 실행 할거 같고, 키 값이 100인 멤버를 find()를 통해 select 해올 것 같다. 하지만 영속 컨텍스트 동작 메커니즘에 의해 persist()시점에 객체는 영속성 컨텍스트에 저장이 된다.
그 후 find()호출 시 DB에서 값을 가져오는게 아닌 영속성 컨텍스트를 참조해서 값을 가져온다. 그리고 마지막 commit 시점에 INSERT 쿼리가 1번만 실행되는 방식으로 동작, 그러나 단위가 트랜잭션 단위이기 때문에 엄청나게 성능 향상은 아님
객체의 동일성 보장
```
public void process(){
   Member member = emtityManager.find(Member.class,100L);
 Member member = emtityManager.find(Member.class,100L);
}
```
1차 캐쉬를 통해 SELECT문도 1번만 발생, 1차 캐쉬를 통해 REPEATABLE READ 격리수준을 DB 차원이 아닌 어플리케이션 차원에서 제공해줌
트랜잭션을 지원하는 쓰기 지연
1번 1차캐시에서 설명한 내용처럼 psersist()시점에 DB에 INSERT를 실행하는게 아닌 commit 시점에 추가/수정/삭제 쿼리를 발생 시킴, 이는 1차 캐쉬와 별도로 쓰기 지연 SQL 저장소라는 공간에서 SQL문을 관리하기 때문,
이는 버퍼링의 기능을 사용함, DB에 여러번 접속이 아닌 JDBC.batch() 를 통해 한번에 쿼리를 동작시킴
변경 감지 ( Dirty Checking)
아래와 같은 상황에서 언제 DB에 업데이트가 반영이 될까?
```
public void process(){
 Member member = entityManager.find(Memeber.class,100L);
 member.setName("Lee's GrowUp");
 // entityManager.persist(member) ; 주석처리
}
```
사실 객체가 영속상태인 경우 entityManager.persist() 메소드 호출 없이 영속성 컨텍스트가 자동으로 UPDATE 쿼리를 발생 시킴, 이는 1차 캐쉬에 객체의스냅샷을 저장하는 영역이 추가로 있는데, commit 시점 또는 flush() 시점에 스냅샷과 현재 Entity를 비교해 다르면 UPDATE 쿼리를 발생시킴
지연 로딩( Lazy Loading )
```
public void process(){
   Member member = entityManager.find(Member.class,100L);
 member.getDepartment(); // 필드로 Department 클래스를 가짐
}
```
위와 같이 Member 클래스가 필드로 Department를 가지는 경우, find(member) 시점에는 MEMBER SELECT만 발생하고, getDepartment()를 호출하는 순간 DEPARTMENT 를 SELECT한다.

플러시

그렇다면 EntityManager은 commit에서만 DB에 SQL을 동작시킬까? flush()를 사용하면 강제로 쓰기지연 SQL 저장소에 있는 SQL 문을 동작시킴

동작시점

entityManager.flush() 호출
트랜잭션 커밋 : 자동호출
JPQL 쿼리 실행

위와 같은 경우에 flush()가 동작하며 영속성 컨텍스트에있는 값은 변경이 없고 쓰기지연 SQL 저장소의 값만 DB와 연동시키고 초기화 한다고 생각하면 됩니다.
보시면 JPQL이라고 JPA에서 지원하는 SQL 언어에서도 flush()가 동작한다고 했는데 이유는 무엇일까?
아래 코드를 보시면 문제점이 보일겁니다.

  public void process(){
      entityManager.persist(member1);
    entityManager.persist(member2);

    query = entityManger.createQuery("select m from member m",Member.class);
    List<Member> members = query.getResultList();
  }

위와 같은 코드에서 영속성 컨텍스트의 메커니즘을 이해하셨으면 문제가 보이실겁니다. 바로 해당 로직에서는 flush()가 동작하지 않았습니다. 즉, member1과member2는 현재 DB에 저장되어 있지 않은 상태에서 쿼리를 실행해 DB에 값을 불러올 경우 데이터가 누락되는 현상이 발생하기 때문에 예외적으로 JPQL에서도 flush()가 동작합니다.

플러시 모드 설정

단 위와 같은 동작 방식이 불필요한경우, JPQL에서 flush()가 동작하지 않게 하는 방법도 존재합니다.

em.setFlushMode(FlushModeType.COMMIT) : 커밋시점에만 동작
em.setFlushMode(FlushModeType.AUTO) : 기본 동작

준영속 상태

영속성 컨텍스트에서 분리시킴으로써 필요한 로직에서 사용

public void process(){
    Member member = entityManager.find(Member.class,100L);
    member.setName("changeName");

    entityManager.detach(member);
}

원래라면 메커니즘에 의해 commit 시점에 UPDATE 쿼리가 발생해야 하지만, 해당 로직에서는 SELECT 문만 발생

비슷한 기능

entityManager.clear() : 영속성 컨텍스트를 전부 초기화
entityManager.close() : 영속성 컨텍스트를 종료

[Gradle] Window에 설치 Gradle 설치하기

효기로그 — Fri, 6 Dec 2019 15:19:47 +0900

Gradle

Gradle는 빌드 자동화 시스템으로, 빌드 툴인 Ant Builder과 Groovy 스크립트 기반으로 구축
자세한 내용은 아래 위키를 참조하시길 바랍니다.

https://en.wikipedia.org/wiki/Gradle

Gradle - Wikipedia

Gradle is an open-source build-automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven for declaring the project configuration.

en.wikipedia.org

Gradle 설치하기

1. 다운로드

아래 그래들 공식 홈페이지에서 원하는 Releases를 complete버전으로 다운로드 해주고, 원하는 위치에 압축을 풀어줍니다.

https://gradle.org/releases/

Gradle | Releases

Find binaries and reference documentation for current and past versions of Gradle.

gradle.org

2. 환경설정

자바의 JDK처럼 윈도우에서 gradle를 호출하기 쉽게 PATH를 설정해줍니다.
내PC -> 속성 -> 고급 시스템 설정 -> 고급 -> 환경변수 -> Path -> 편집 후 등록
여기서 등록은 %Gradle 설치경로%\bin 으로 등록해줍니다. ( ex : C:\gradle-5.6.4\bin )

내PC 오른쪽 마우스 클릭 -> 속성 클릭

고급 시스템 설정 클릭

고급 탭 -> 환경변수 -> 시스템 또는 사용자의 Path 설정

위 과정까지 완료 되었다면 이제 cmd (커맨드창) 을 열어주고 gradle -v 를 입력해줍니다.

위 사진과 같이 버전 정보가 표시되면 설치 및 환경변수 설정이 끝납니다.

[Spring/Tiles-framework] page 전환 없이 body만 변경 / content만 새로고침 load

효기로그 — Thu, 5 Dec 2019 15:57:15 +0900

이번 포스팅에서는 Tiles에 대한 설명은 생략하겠습니다. 사실상 키워드를 저렇게 검색하고 오셨다는거는 이미 Tiles Framework를 사용한다는 가정하에 있으시니까.바로 특정 타일만 페이지 로드 없이 ajax콜을 통해 동적으로 변경하는 방법을 소개하겠습니다.

구조 이미지

기존 구조

대충 위와 같은 구조의 홈페이지라고 가정했을 때 BODY || CONTENT 영역 부분만 바꾸고 싶을때입니다.
우선 기존의 tiles.xml 파일은 아래와 같았습니다.

tiles.xml

<tiles-definitions>

    <definition name="layouts-tiles" template="/WEB-INF/jsp/common/default-layouts.jsp"></definition>

      <definition name="/*/*.do" extends="layouts-tiles">
           <put-attribute name="content" value="/WEB-INF/jsp/{1}/{2}.jsp" />
       </definition>

       <definition name="/common/loginPage.jsp" template="/WEB-INF/jsp/common/loginPage.jsp">
       </definition>

</tiles-definitions>

다음으로 HTML 구조입니다.

default-layouts.jsp

    ... 헤더, 메뉴 등등...공통으로 들어갈 화면 정의
    <div class="layout-body">
        <div class="layout-inner-body">        
            <tiles:insertAttribute name="content"/>
         </div>
    </div>

위와 같은 방식으로 헤더나, 메뉴, 푸터는 간단하게 한 페이지로 구성하고, content부분만 변경하는 구조입니다.
이렇게 사용하면 해당 페이지를 새로 불러올때 불필요하게 공통부분을 include할 필요 없이 content부분만 바뀌어서 화면이 로드가 됩니다. 그치만 저같은 경우 헤더나, 메뉴에서 사용하는 외부 라이브러리가 많아 호출마다 0.5초씩 응답 시간이 필요해 화면이 깜빡이는 것 처럼 보이는게 싫었습니다.

그래서 공통 스크립트나, css 같은건 한번만 로드하고 가운데 conetent영역만 바꾸고 싶었기 때문에 제가 선택한 방법은 우선은 빈 껍데기인 html을 하나 만들고 <tiles:insertAttribute name="content"/> 만 선언해줍니다.

변경 구조

위에 언급처럼 빈 껍데기인 하나의 html 파일을 생성해줍니다.

empty.html

<!-- empty.jsp -->
<tiles:insertAttribute name="content"/>

그리고 기존의 tiles.xml을 수정해줍니다.

tiles.xml

<tiles-definitions>

    <definition name="layouts-tiles" template="/WEB-INF/jsp/common/default-layouts.jsp"></definition>

      <definition name="/*/*.do" extends="layouts-tiles">
           <put-attribute name="content" value="/WEB-INF/jsp/{1}/{2}.jsp" />
       </definition>

       <definition name="/common/loginPage.jsp" template="/WEB-INF/jsp/common/loginPage.jsp">
       </definition>

    <definition name="empty" template="/WEB-INF/jsp/common/empty.jsp">
         <put-attribute name="content" value=""/>
    </definition>

    <definition name="*/empty/*.do" extends="empty">
        <put-attribute name="content" value="/WEB-INF/jsp/{1}/{2}.jsp" />
    </definition>
</tiles-definitions>

이렇게 빈 empty.jsp 과 default-layouts.jsp 의 <tiles:insertAttribute name="content"/> 을 연결해줍니다. 그리고 처음 언급처럼 ajax 호출을 통해 넘겨 받은 값으로 대체해줍니다. 아래는 예제 함수입니다.

예제 페이지 변경 함수

function changeContents(url){
        $.ajax({
            type        :    "get",
            url : "<c:url value='url'/>",
            dataType    :    'html',
            success        :    function(data){
                $(".layout-inner-body").children().remove();
                $(".layout-inner-body").html(data);

                // 접속 URL만 페이지 변환없이 변경
                // IE 10 이상이서만 지원...
                history.pushState({"html":data},'',currentMenuUrl) 
            }
            , beforeSend: function() {

            },
            complete:function(){
            }
           });

    }

간단하게 구현한 방식이며, 위와 같이 사용합니다.

[인강리뷰] 자바 ORM 표준 JPA 프로그래밍 - 기본편

효기로그 — Thu, 5 Dec 2019 13:01:21 +0900

개인적으로 공부하다가 JPA, ORM, Hibernate 등등.. 단어들을 인터넷을 통해 자주 접하게 되어서 블로그나 참고자료를 찾아보는데 내용이 복잡해서 관련 책을 알아보다가 찾아냈다. 저자는 현재 우아한형제들 개발 팀장으로 계시는 김영한님이다.
해당 책은 Inflearn을 통해 인강으로도 제공해주고 있기 때문에 독학에는 인강이 조금 더 이해하기 쉬울 거 같아서 인강을 선택하였다.

이런 걸 배울 수 있어요

JAP의 기본기를 탄탄하게 다질 수 있습니다.
JAP의 내부 동작 방식을 이해할 수 있습니다.
객체와 DB 테이블을 올바르게 설계하고 매핑할 수 있습니다.
실무에서 자신있게 JPA를 사용할 수 있습니다.

자바 ORM 표준 JPA 프로그래밍 - 기본편

객체를 관계형 데이터베이스에 저장하려면 개발자는 많은 코드와 SQL을 작성해야 합니다. 예를 들어 객체를 SQL로 변환하는 단순한 일부터, 객체의 상속 구조를 테이블에 저장하는 복잡한 일까지, 개발자는 객체와 데이터베이스 사이에서 무수한 매핑 코드와 SQL을 직접 작성해야 합니다. 자바 ORM 표준인 JPA는 SQL 작성 없이 객체를 데이터베이스에 직접 저장할 수 있게 도와주고, 객체와 관계형 데이터베이스의 차이도 중간에서 해결합니다.

강의 목표

앞으로 진행할 JPA 강의는 크게 기본편과 활용편으로 나뉘어져 있습니다. 이 강의는 기본편입니다.

마치며

뭐 대충 강의 내용은 이러하고 자세한 내용은 인프런을 통해서 확인하시길 바라겠습니다.

사실상 가격이 부담되다 보니 구매를 망설이던 강의였는데, JPA나 Hibernate가 왜 등장했고 어떤 방식으로 동작하는지 핵심 기술부터 차근차근 설명해주기 때문에 만약 JPA를 쓰시는 분이라던가 책으로 공부중인데 이해가 어려우신 분들은 인강과 책을 같이 공부하면 더욱 도움이 될 것 같다고 생각이 들었습니다.

이상으로 강의를 보고 내용을 블로그에 조금씩 정리할 계획입니다.

JPA와 ORM의 기본 개념

[JAVA/JPA] JPA 와 ORM 기본 개념 Hibernate ORM

lee1535.tistory.com

JAP의 영속성 컨텍스트

[JAVA/JPA] 영속성 컨텍스트 EntityManage JPA 동작 방식

해당 내용은 인프런의 자바 ORM 표준 JPA 프로그래밍 - 기본편 , 김영한 의 내요을 기반으로 정리해서 작성한 글입니다. 자세한 내용은 해당 강의 또는 책을 구매하셔서 알아보시는걸 추천합니다. 해당 글을 읽기..

lee1535.tistory.com

[JAVA/JPA] JPA 와 ORM 기본 개념 Hibernate ORM

효기로그 — Thu, 5 Dec 2019 09:34:49 +0900

해당 내용은 인프런의 자바 ORM 표준 JPA 프로그래밍-기본편 - 김영한 의 내용을 기반으로 정리해서 작성한 글입니다.
자세한 내용은 해당 강의 또는 책을 구매하셔서 자세히 알아보시는걸 추천합니다.

ORM 이란?

ORM(Object-relational mapping)의 약자로써, 객체와 관계의 연결을 시켜주는 것을 말한다. 즉 Java와 같은 객체 지향 언어에서의 객체와 Oracle와 같은 RDB를 연결 시켜주는 방식을 말하며, Hibernate는 Java에서 사용하는 ORM의 open source Framework의 한 종류이다.

JPA 란?

JPA(Java Persistent API)의 약자로 말 그대로 자바에서 사용하는 ORM 기술에 대한 API 표준 명세를 뜻합니다.
JPA는 ORM을 사용하기 위한 인터페이스를 모아둔 것입니다.

등장 배경

위에서 ORM과 JPA에 대해서 간략하게 어떤 내용인지 설명을 했고, 그렇다면 왜 등장했을까?
ORM의 정의처럼 현재 프로그래밍 방식인 객체지향적 방식과 DB의 관계지향적 방식의 불일치
즉 페러다임의 불일치로 인해 문제가 발생하며, 프로그래밍을 객체보다 테이블을 우선시 작성하며, 객체를 단순히 데이터 전달의 목적으로( DTO, VO 등 ) 사용

페러다임의 불일치로 발생하는 문제

객체다운 모델링 문제
- 간단하게 객체지향 적으로 모델링을했다고 가정하고, 객체의 필드로 객체를 가지는 경우
```
public class Member {
  private String name;
  private Department dept;

  getter()/setter()
}
```
  위와 같이 객체지향적으로 사용을 할경우 Member클래스와 Department 클래스를 모두 사용할 때, DB에서 MEMBER 테이블과 DEPT 테이블을 조인해 결과를 가지고 왔다고 가정했을 경우 로직에서 new Member()로 인스턴스하고 값 매핑시켜주고, 추가로 new Departemt() 를 통해서 또 매핑시켜주고..이런 동작이 필요하게 됨
  그래서 MemberDepartemtDTO 대충 이런식으로 큰 클래스를 넣고 거기서 Member클래스의 필드와 Departemt 필드를 다 넣어서 사용 이는 객체지향적이지 못한 방식의 프로그래밍
객체의 탐색 범위 문제
SQL은 데이터가 쿼리문에서 조회해온 데이터로 한정적이기 때문에 엔티티 신뢰에 문제가 발생
간단하게 설명해 SQL 쿼리를 통해 MEMBER 테이블에서 name을 가져오는 쿼리를 실행했다고 가정하고, 매핑되는 Member 객체는 field로 String name, int age를 가지고 있다고 가정해봅니다.
```
  public void process() {
    Member member = memberDAO.getMember(memberId);
    member.getName() // 가능
    member.getAge() // 값이 없음
  }
```
위 예제를 보면 우리는 member객체를 통해서 getName()는 가능하고 getAge()는 값이 없다는걸 당연하다고 생각할 것입니다.
왜?? 우리는 현재 쿼리가 어떻게 동작하고 어떤 값을 가져오는지 알고 있다는 가정하에 있으니까 가능합니다. 그러나 다른 사람이 작성한 코드의 경우, 예전에 만들어두고 까먹은 경우
해당 값이 어떤 값을 매핑하는지는 보통 해당 Service -> DAO -> SQL 을 탐색해서 해당 쿼리문을 보고 받아오는 값을 확인합니다.

객체의 동일성 보장이 안된다
```
public void process() {
  Member member1 = memberDAO.getMember(100);
  Member member2 = memberDAO.getMember(100);
  System.out.println(member1 == member2 ) // false
}
```
위와 같이 실행했을 경우 member1과 member2는 동일한 객체일까요? 아쉽게도 JDBC API 메커니즘에 의해 전혀 새로운 객체로 취급받습니다. 그렇다면 우리가 흔히 생각하는 객체지향적으로 봤을때 두 객체는 같아합니다. 예제는 컬렉션을 기준으로 하겠습니다.
```
public void process() {
  Member member1 = memberList.get(100);
  Member member2 = memberList.get(100);
  System.out.println(member1 == member2 ) // true
}
```
위 둘 예제에서 객체의 동일성이 보장이 안되는 문제가 발생합니다.

객체지향의 장점인 ( 추상화, 캡슐화, 상속, 다형성 ) 을 활용하지 못함
예를들어 상속관계인 객체의 경우 자바 컬렉션에서는
```
public void process() {
  Book book = list.get(bookId);
  Item item = list.get(bookId);
}
```
위와 같이 다형성등을 사용해 간단하게 사용 가능하지만, DB에 저장하기 위해서는
- 객체를 분해
- INSERT INTO ITEM...
- INSERT INTO BOOK...
  위와 같은 방식으로 동작하며 조회시에도 복잡한 작업이 많이 요구됩니다. 그래서 DB에 저장할 객체에는 상속 관게를 사용하지 않는 문제점 발생

JPA를 통한 문제 해결

JPA를 사용하면 패러다임의 불일치에 대한 불필요한 처리를 해결해준다.

객체답게 사용 가능
아래의 방식처럼 객체간 연관관계가 끊기는 방식으로 동작하는 기존의 테이블의 데이터 중심의 설계에서
```
public class Member {
     String name;
    String deptId;
}
public void process(){  
    Member member = new member();  
    Department dept = memberDAO.getDepartment(member.getDeptId());  
}
```
아래와 같이 객체의 연관관계를 사용할 수 있게 해줍니다. 단, JPA의 핵심이기한 객체지향적 모델링이 요구됩니다.
그만큼 모델링 자체를 객체지향적인 관점에서 해야 하기 때문에 제일 어려운 부분입니다. 또한 객체관의 관계가 단방향인지, 양방향인지, 관계의 주인은 누구인지를 잘 파악하고 사용하셔야 합니다.
```
public void process(){  
  Member member = new member();  
  Department dept = member.getDept();  
}
```

객체의 탐색 범위 문제 해결
위 예제처럼 동일한 상황에 SQL에 의존적이지 않고 객체의 필드를 필요하면 사용이 가능
```
public void process() {
  Member member = memberDAO.find(memberId);  
  member.getDepartemt();  
  member.getAge(); //가능
}
```
또한 객체 그래프 탐색가능
```
public void process() {
  Member.setTema(new Team());  
  jpa.persist(member); // 객체를 DB 지향적으로 teamId값이 아닌 객체 자체를 넣음

  // 조회도 가능  
  Member member = jpa.find(member.class, memberid)  
  Team tem = member.getTeam()
}
```
여기서 persist(),find()는 JPA에서 제공하는 메소드이고, 위와 같이 동작이 가능한 이유는 지연 로딩을 제공하기 때문입니다. 자세한 내용은 아래에 추가로 설명하겠습니다.
객체의 동일성 보장 ( 단 같은 트랜잭션의 단위 -> jpa에서는 트랜잭션 단위가 중요함 )
JPA에서 중요한 EntityManager(영속성 컨텍스트)가 트랜잭션 단위로 생성과 소멸이 되기 때문

JPA의 장점

위 객체지향과 관계모델의 페러다임 불일치 해결과 함께 제공해주는 JPA의 장점입니다.

SQL 중심적 개발에서 객체 중심 개발 -> SQL에 의존적이지 않음 -> 생산성 증가
따로 SQL문 작성이 필요없이 몇개의 메소드로 동작함. 나머진 자동으로 SQL문 생성해줌
페러다임 불일치 해결
성능 향상
- 1차 캐시를 사용
  단 트랜잭션 단위에서만 지원함
  어플리케이션 자체에서 DB Isolation Level을 Read Commit 이여도 Repeatable Read을 보장
- 트랜잭션을 지원하는 쓰기 지연
  JDBC batch() 기능, 여러개의 비슷한 쿼리를 한번에 묶어서 보냄 (버퍼처럼 )
  update, delete시 DB Lock를 최소화 하기 위해 커밋 직전에 실행 위 insert도 동일
- 지연 로딩
  Member 객체만 사용할 경우 SQL이 MEMBER 테이블에서만 조회 하다가 getDepartemt() 시점에 DEPARTMENT 테이블을 참조해 값을 가져옴
  그러나 매번 두 테이블을 같이 쓰는 경우 불필요하게 select문이 많아질 수 있기 때문에, 즉시로딩 즉 member/team을 한번에 가져오는 방식도 지원해준다. 필요한 방식으로 사용하면 됩니다
데이터 접근 추상화와 벤더 독립성
데이터 접근에 대한 SQL문을 몰라도 되고, Oracle,MySQL 등 특정 DB에 종속적이지 않게 사용이 가능, 이는 persistence.xml에 옵션으로 dialect 설정을 통해 자동으로 쿼리를 완성해줌, 이는 장점이자 단점이 될 수도 있을거 같다는 생각이 듭니다.

JPA의 단점

성능이 떨어진다. 자동으로 쿼리를 완성해준다는 부분이 원하는 쿼리를 수행하지 않을 경우도 존재한다는 말이고, 성능도 좋지 못했다고 합니다. 그러나 지금은 여러가지 보안을 하여서 잘만 이해하고 사용하면 1차 캐쉬등을 통해서 더 좋은 성능을 낼 수 있다고 생각합니다. 또한 전세계적으로 사용중이기 때문에 꾸준한 발전이 되고 있습니다.
세밀함이 떨어진다. 자동 SQL 완성으로인헤 통계를 구하는등의 세밀한 작업이 떨어집니다. 그래서 JPQL이라는 별도의 언어를 제공해주고 또한 SQL 자체도 수행 가능하도록 지원하고 있습니다.
러닝커브 사용하기 위해 비용이 많이 들어갑니다.. 제대로 사용하기 위해 시간을 투자해야한다.

[Web] WAS 와 웹서버란? ( WAS, Web Server ) 아파치 (apache) 톰캣 (tomcat )

효기로그 — Fri, 29 Nov 2019 11:05:18 +0900

올해 초 웹 개발자 면접을 진행하면서
WAS와 Web Server의 차이는 무엇인가요? 라는 질문을 많이 들었던것 같다.
답변으로 정적인 페이지 처리와, 동적인 페이지처리의 차이가 있다. 라고 기본적인 답변을 했었습니다.

그리고 어떻게 동작하는지 아시나요? 라고 질문을 하신 분들도 계셨는데
답변으로 html과 css같은 정적문서 요청인 경우 Web Server 가 처리하고 JSP,Script 같이 동적문서 요청인 경우 WAS가 처리한다고 답변을 했었습니다.

위에 말이 틀린말은 아니지만, 이번 포스팅에서는 좀 더 어떤 방식으로 동작하는지에 대해서 구체적으로 공부를 하기 위한 포스팅이 목적입니다.

1. 전체 구조

Web Server 란 ?

클라이언트의 request가 오면 요청에 대한 처리를 담당하며
정적문서( html, css ) 등일 경우 요청에 응답을 해줍니다. 대표적으로 Apache 에 해당합니다.

동작

요청이 정적 컨텐츠일 경우 제공
요청이 정적 컨텐츠가 아닐 경우 WAS로 처리를 위임 후, 넘어온 값을 응답

WAS ( Web Application Server ) 란 ?

동적 컨텐츠를 제공하기 위해 만들어진 미들웨어로써, DB조회가 필요하거나 처리가 필요한 JSP/Servlet 구동 환경을 제공합니다.
대표적으로 Tomcat가 있습니다.

동작

Web Server로 부터 요청이 오면 컨테이너가 응답
컨테이너는 JSP/Servlet을 실행
컨테이너는 요청 결과를 HTML 문서로 만들어 Web Server로 전달

Web Server 과 WAS의 차이

동적 컨텐츠처리와 정적 컨텐츠 처리의 역할을 분리해서 WAS 서버의 부하 방지
WAS가 불필요한 경우 Web Server이 처리를 함으로써 성능 향상 ?
일부는 맞고 일부는 틀린말이라고 생각합니다. 과거에는 WAS에서 정적 컨텐츠 처리 기능을 제공하지 않았지만, 요즘 WAS는 내부에 HTTPD의 일부 기능을 제공하기 때문에 속도의 차이는 없다고 합니다.

그렇다면 왜 사용하는 것일까?

1번에서 말한거 처럼 WAS 서버의 부하를 방지
물리적으로 분리하여 ( Web Server과 WAS 서버의 포트가 다름 ) 보안강화
위 구조 그림처럼 여러대의 WAS를 연결하여 사용 가능, 로드밸런싱의 역할
- 이는 java서버, php서버 등 하나의 웹서버를 통해 서비스가 가능

[자바/알고리즘] 프로그래머스 자릿수 더하기

효기로그 — Thu, 28 Nov 2019 16:51:06 +0900

문제 설명

자연수 N이 주어지면, N의 각 자릿수의 합을 구해서 return하는 solution함수를 만들어 주세요.
예를들어 N = 123 이면 1 + 2 + 3 = 6 을 return 하면 됩니다.

제한 사항

N의 범위 : 100,000,000 이하의 자연수

입출력 예

N	answer
123	6
987	24

입출력 예 설명

입출력 예 #1

문제의 예시와 같습니다.

입출력 예 #2

9 + 8 + 7 = 24이므로 24를 return 하면 됩니다.

나의 풀이

public class Solution {
    public int solution(int n) {
        int answer = 0;
        while(true){
            answer += n%10;
            if(n<10) break;
            n = n/10;
        }
        return answer;
    }
}

풀이 설명

%연산자를 통해서 해당 자리의 자릿수를 answer에 더해줍니다.
그 후, 다른 자릿수를 구하기 위해 전체 값에 /10을 통해 자릿수를 이동해줍니다.
마지막까지 탐색 후 더한값 즉 answer을 리턴해줍니다.

[자바/알고리즘] 프로그래머스 자연수 뒤집어 배열로 만들기

효기로그 — Thu, 28 Nov 2019 16:34:33 +0900

문제 설명

자연수 n을 뒤집어 각 자리 숫자를 원소로 가지는 배열 형태로 리턴해주세요. 예를들어 n이 12345이면 [5, 4, 3, 2, 1]을 리턴합니다.

제한 조건

n 은 10,000,000,000 이하인 자연수입니다,

입출력 예

n	return
12345	[5,4,3,2,1]

나의 풀이

class Solution {
  public int[] solution(long n) {
      int[] answer = new int[String.valueOf(n).length()];
      for (int i = 0; i < answer.length; i++) {
            answer[i] = (int) (n%10);
            n /= 10;
        }
      return answer;
  }
}

풀이 설명

우선 자연수를 뒤집어 저장한다 -> 즉 1의자리부터 10의자리 100의자리...의 값으로 저장하면 된다. 라고 접근을했습니다.
그래서 넘어온 매개변수 n의 길이만큼 int[]배열의 크기를 초기화 해주고,

%연산을 통해 해당 자리의 값을 추출
/연산자를 통해 다음 자릿수로 이동

의 로직을 반복문을 통해 실행하고 리턴하였습니다.

[자바/알고리즘] 프로그래머스 정수 내림차순으로 배치하기

효기로그 — Thu, 28 Nov 2019 13:14:41 +0900

문제 설명

함수 solution은 정수 n을 매개변수로 입력받습니다. n의 각 자릿수를 큰것부터 작은 순으로 정렬한 새로운 정수를 리턴해주세요. 예를들어 n이 118372면 873211을 리턴하면 됩니다.

제한 조건

n은 1이상 8,000,000,000 이하인 자연수입니다.

입출력 예

n	return
118372	873211

나의 풀이

import java.util.Arrays;
import java.util.Comparator;
class Solution {
  public long solution(long n) {

        String[] sarr = (String.valueOf(n)).split("");

        Arrays.sort(sarr,new Comparator<String>() {
            @Override
            public int compare(String str1, String str2) {
                // TODO Auto-generated method stub
                return(str2).compareTo(str1);
            }
        });
      return Long.parseLong(String.join("", sarr));
  }
}

풀이 설명

넘어온 숫자를 자릿수로 정렬하기 위해 각 자릿수의 숫자를 각각 String[]배열에 저장하고 싶었다.
그래서 사용한 방법이 넘어온 매개변수 n을 String.valueOf(long) 메소드를 통해 타입을 String 형으로 바꾸고,
String의 메소드 split()를 이용해 한글자씩 추출했습니다.
그 후, Arrays.sort() 를 사용해 내림차순 정렬을 한 후, 값을 리턴해줍니다.

[디자인패턴/Design Patter] Prototype 패턴 프로토타입 패턴

효기로그 — Wed, 27 Nov 2019 13:01:59 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문] 이라는 책의 공부 내용을 개인적으로 정리한 내용입니다.
처음 배우는 부분이기 때문에 틀린 부분이 있다면 지적해주시면 감사하겠습니다.

1. Prototype 패턴이란?

Prototype는 '원형' 이라는 의미로, 원형이 되는 인스턴스로 새로운 인스턴스를 만드는 방식, 즉 객체에 의해 생성될 객체의 타입이 결정되는 생성 디자인 패턴입니다.

2. Prototype 패턴의 등장인물

이번 포스팅에서 사용될 요소들의 역할입니다.

Prototype의 역할
1. 인스턴스를 복사하여 새로운 인스턴스를 만들기 위한 메소드를 결정
ConcretePrototype
1. 인스턴스를 복사해서 새로운 인스턴스를 만드는 메소드를 실제로 구현
Client
1. 인스턴스 복사 메소드를 사용해서 새로운 인스턴스를 만듭니다.

Prototype 패턴의 클래스 다이어그램

3. 예제

이제 Prototype 패턴의 예제로 내용을 구체화 해보겠습니다.

예제에서 사용될 클래스 다이어그램

Shape 클래스

clone() 메소드를 사용하기 위해 Cloneable 인터페이스를 구현하며, 공통 메소드인 draw()는 추상 메소드로 정의하고,
하위 클래스에서 사용할 clone()는 공통으로 동작하는 메소드를 정의

public abstract class Shape implements Cloneable{
    protected Type type;

    abstract void draw();

    @Override
    public Object clone() throws CloneNotSupportedException {
        Object clone = null;

        try {
            clone = super.clone();
        } catch (RuntimeException e) {
            e.printStackTrace();
        } catch (CloneNotSupportedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        return clone;
    }
}

상황에 따라 clone()메소드를 공통으로 동작하지 않게 할 경우, 해당 클래스 자체를 interface로 선언 후,
clone()메소드 정의를 하위 클래스에 위임 하는 방식도 존재
여담으로 clone() 의 try - catch 문에서는 어차피 Clonable 인터페이스를 구현했기 때문에 CloneNotSupportedException 이 발생하지 않는다. 그래서 추가로 RuntimeException 을 catch문에 추가 해주는 방식이 좋다.

Circle, Triangle, Rectangle 클래스

각각 Shape 클래스를 상속 받으며 draw()메소드를 재정의한다. 해당 소스는 Circle 클래스 기준입니다.

public class Circle extends Shape {
    public Circle() {
        this.type = Type.CIRCLE;
    }

    @Override
    void draw() {
        System.out.println("[Circle]입니다.");    
    }
}

ShapeStroe 클래스

저장소를 담당하며, 최초 registerShap() 메소드 호출 시 복제에 사용할 객체를 인스턴스화 해서 shapeMap에 저장하는 동적을 하며, getShape()메소드를 통해 객체의 복사본을 반환해주는 역할을 합니다.

public class ShapeStore {
    private static Map<Type, Shape> shapeMap = new HashMap<Type, Shape>();

    public void registerShape() {
        Rectangle rec = new Rectangle();
        Circle cir = new Circle();
        Triangle tri = new Triangle();

        shapeMap.put(rec.type, rec);
        shapeMap.put(cir.type, cir);
        shapeMap.put(tri.type, tri);
    }

    public Shape getShape(Type type)  {
        return (Shape) shapeMap.get(type).clone();
    }
}

사람에 따라 해당 로직을 Client 해당 예제에서는 Main 클래스에서 정의하는 방식도 존재하지만,
저의 경우 Client와 역할을 분리해 해당 소스가 변경이 있어도 추가로 수정하는 부분이 없도록 역할을 분리해서 작성했습니다.

Main 클래스

마지막으로 Client에 해당하는 부분입니다. 복제된 객체를 사용합니다.

public class Main {
    public static void main(String[] args) {
        ShapeStore manager = new ShapeStore();
        manager.registerShape();

        Circle cir1 = (Circle)manager.getShape(Type.CIRCLE);
        cir1.draw();
        Circle cir2 = (Circle)manager.getShape(Type.CIRCLE);
        cir2.draw();

        Rectangle rec1 = (Rectangle)manager.getShape(Type.RECTANGLE);
        rec1.draw();

        Triangle tri1 = (Triangle)manager.getShape(Type.TRIANGLE);
        tri1.draw();

    }
}

실행 결과

[Circle]입니다.
[Circle]입니다.
[Rectangle]입니다.
[Triangle]입니다

그렇다면 왜 사용하는 것일까?

1. 객체의 생성이 값비싼 경우 ( DB를 참조하는 등 ) 객체 생성의 비용을 줄일 수 있습니다.

고려할 사항

그러나, 예제에서 사용된 clone()메소드는 Object 클래스의 메소드로 써, 얕은 복사로 동작을 합니다.
그렇기 때문에 깊은 복제를 사용해야 할 경우 clone()메소드를 재정의 해야 합니다.
위와 같은 문제로 복제된 객체의

순환 참조나 깊은복사 얉은 복사에 대한 고민이 필요

4. 관련패턴

Flyweight 패턴 : 프로토타입과 다르게 하나의 인스턴스를 복수의 장소에서 공유해서 이용
Memento 패턴 : 스냅샷과 undo를 실행하기 위해 인스턴스의 상태를 저장합니다.
Composite 및 Decorator 패턴 : 둘을 사용하면 복잡한 구조의 인스턴스가 동적으로 만들어지는 경우가 있는데, 이와 같은 경우 프로토 타입 패턴을 사용하면 편리합니다.
Command 패턴 : 해당 패턴의 명령을 복제하고 싶은 경우 프로토타입 패턴을 사용

[디자인패턴/Design Pattern] Singleton 패턴 / 싱글톤 패턴

효기로그 — Tue, 26 Nov 2019 09:49:09 +0900

관련 내용은 [자바 언어로 배우는 디자인 패턴 입문] 이라는 책의 공부 내용을 개인적으로 정리한 내용입니다.
처음 배우는 부분이기 때문에 틀린 부분이 있다면 지적해주시면 감사하겠습니다.
또한 관련 내용은 Effective Java의 내용도 포함되어 있습니다.

1. Singleton 패턴이란?

생성자가 여러 차례 호출되어도 실제 생성되는 객체는 최초의 1개이고, 그 이후의 생성자는 최초 생성자를 통해 생성한 객체를 리턴하는 방식입니다. 즉, 인스턴스가 1개 밖에 존재하지 않는 것을 보증하는 패턴입니다.

2. Singleton 패턴의 등장 인물

이번 포스팅에서 사용될 요소들의 역할입니다.

Singleton의 역할
1. 유일한 인스턴스를 얻기 위한 static메소드를 가지며. 이 메소드는 언제나 동일한 인스턴스를 반환하는 역할

Singleton 패턴의 클래스 다이어그램

3. 예제

이제 Singleton의 예제로 내용을 구체화 해보겠습니다. 다만 Singleton 방식에 대해서 책의 내용은 입문 책이라 그런지 가장 고전적인 방법을 안내해주고 있어서 추가로 내용을 정리해서 올립니다.

3-1. 이 책에서 소개하는 Singleton 패턴

가장 기본적인 singleton 패턴 방식이며, 아래 내용을 이해하기 위한 기본 구조입니다. 하지만 환경에 따라 여러 문제점이 발생하기 때문에 해결법은 아래에서 추가로 설명하겠습니다.

public class Singleton {
    private static Singleton singleton = new Singleton();
    private Singleton() {
        System.out.println("인스턴스를 생성했습니다.");
    }
    public static Singleton getInstance() {
        return singleton;
    }
}

문제점

위와 같은 방식으로 Singleton 을 정적 팩토리 방식으로 생성하면, 간결하다는 장점이 존재한니다.
하지만 Reflection에 의해서 객체의 인스턴스는 단 1개만 보장한다는 방식이 파괴되며, 직렬화 과정에서 같은 객체라는 보장이 되지 않습니다. 아래 예시에서 Reflection에 대한 예시를 설명하겠습니다. 직렬화에 대한 테스트는 독자분들에게 맡기겠습니다.

싱글톤 파괴

public class Main {
    public static void main(String[] args) throws Exception {

        StaticFactorySingleton singleton1 = StaticFactorySingleton.getInstance();
        System.out.println(singleton1.hashCode());

        Constructor cs = StaticFactorySingleton.class.getDeclaredConstructor();
        cs.setAccessible(true);

        StaticFactorySingleton singleton2 = (StaticFactorySingleton)cs.newInstance();
        System.out.println(singleton3.hashCode());
    }
}

위와 같이 실행을 하게 되면 일반적인 호출로는 같은 인스턴스를 반환해주지만, reflection을 사용한 객체는 전혀 새로운 객체를 반환해줍니다.

실행 결과

인스턴스를 생성했습니다.
5433634
인스턴스를 생성했습니다.
2430287

3-2. EFFECTIVE Java에서 소개하는 방법

해당 방식전에 Singleton을 보장( 멀티쓰레드, 직렬화 ) 하기 위한 방식으로 Double Checked Locking 방식이 존재하지만, 현재 사용하지 않는다고 해서 설명은 생략하지만 관련 글을 읽어보면 좋을거 같아서 링크를 남깁니다.

https://medium.com/@kevalpatel2106/how-to-make-the-perfect-singleton-de6b951dfdb0

How to make the perfect Singleton?

Design Patterns are popular among software developers. A design pattern is a well described solution to a common software problem. The…

medium.com

그러면, 본론으로 들어와서 EFFECTIVE Java에서 소개하는 방식을 소개하겠습니다.
내용은 간단합니다. singleton을 사용할 객체를 class가 아닌 enum으로 정의하는 방식입니다. 코드는 아래와 같습니다.

public enum Singleton {
    INSTANCE;
}

위와 같은 방식은 우선 간결하고, 추가의 노력 없이 직렬화가 가능하고, 심지어 멀티쓰레드에서도 안정적입니다. 또한 리플렉션으로 생성자에 접근하지도 못합니다.
하지만 만들려는 Singleton이 Enum 외의 클래스를 상속해야 하거나, java 1.5이하 버전이라든지의 상황에서는 사용이 불가능합니다. 또한 메모리에 대한 성능 이슈도 존재합니다.

3-3. Initialization-on-demand holder idiom 방식

enum 방식은 안드로이드 개발시에 문제가 발생할 수 있어서 해당 방식이 제일 많이 사용하는 방식입니다. 이 방식을 사용하면, 위 본문에 소개에서 생략한 Double Checked Locking 과 같은 방식에서 사용한 synchronized도 필요없어서 성능이 뛰어나고, enum방식처럼 Java 버전에 상관이 없습니다. 코드는 아래와 같습니다.

public class Singleton{
    private Singleton() { }
    public static Singleton getInstance() { 
        return LazyHolder.INSTANCE;
    }

    private static class LazyHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

해당 방식에 대한 설명은 간단히 하자면, 객체가 필요로 할때 초기화를 미뤄서, 불필요하게 메모리를 잡아먹지 않습니다.
Singleton 클래스를 로드를 해도 LazyHolder 클래스의 변수가 없기 때문에 메모리에 할당받지 않습니다.
이는 자바 클래스로더 매커니즘을 이용한 방식으로, Singleton의 getInstance() 메소드를 호출하는 순간 LazyHolder Class가 로딩됩니다.
이 때 Class를 로딩하고, 초기화하는 시점에 JVM에 의해서 thread-safe를 보장하기 때문에, 불필요한 키워드로 인한 성능저하가 없기 때문에 실무에서 가장 많이 사용하는 방식이라고 합니다.
그러나, 다른 방식과 마찬가지로 Reflection을 통해 파괴가 가능합니다.

4.마치며

위와 같으 Singleton을 만드는 방법은 다양하며, 각각 장단점이 존재하니 상황에 따라 필요한 방식으로 선택하면 될 것 같습니다.

5. 관련 패턴

아래 4개는 인스턴스가 1개인 경우가 많이 존재합니다.

Abstract Factory 패턴
Builder 패턴
Facade 패턴
Prototype 패턴 link

[디자인패턴/Design Pattern] Factory Method 패턴 / 팩토리 메소드 패턴

효기로그 — Fri, 22 Nov 2019 11:19:12 +0900

1. Factory Method 패턴이란?

상위 클래스에 알려지지 않은 구체 클래스를 생성하는 패턴이며, 하위 클래스가 어떤 객체를 생성할지 결정하도록 하는 패턴입니다. 또한 부모 클래스 코드에 구체 클래스 이름을 감추기 위한 방법으로도 사용합니다.

Factory Method라는 패턴 이름 때문에 객체를 생성하는 메소드라고 오해할 수 있지만, Template Method의 생성 버전이라고 볼 수 있다.

상속을 사용하지만 상위 클래스를 전혀 확장하지 않기 때문에 extends의 관계를 잘못 이용한 것처럼 보여질 수 있다.

객체 생성에 대한 정의는 하지만, 객체의 생성을 자식클래스(서브클래스)에 위임하는 패턴

2. Factory Method 패턴의 등장인물

이번 포스팅에서 사용될 요소들의 역할입니다.

Product( 제품 ) 의 역할
1. Factory Method 패턴에서 생성되는 인스턴스가 가져야 할 인터페이스를 결정하는 추상 클래스
Creator ( 작성자 ) 의 역할
1. Product의 역할과 인스턴스의 생성 메소드를 가집니다.
2. new 연산자를 사용해 실제 인스턴스를 생성하는 대신에, 인스턴스 생성을 위한 메소드를 호출해서 구체적인 클래스 이름에 의한 속박에서 상위 클래스를 자유롭게 만듭니다.
ConcreteProduct ( 구체적인 제품 ) 의 역할
1. Product의 내용을 정의합니다.
ConcreteCreator ( 구체적인 작성자 ) 의 역할
1. Creator의 내용을 정의합니다.

Factory Method 패턴의 클래스 다이어그램

3. 예제

이제 Factory Method의 예제로 내용을 구체화 해보겠습니다.

예제에서 사용될 클래스 다이어그램

Factory 클래스

Template Method패턴을 사용하고 있습니다.create()라는 메소드를 통해 '생성'한다라는 정의만 하고 자세한 구현은

protected abstract Calculator createCalculator(Calculator.TYPE type, int a, int b) 메소드에게 위임합니다.

public abstract class Factory {
    public final Calculator create(Calculator.TYPE type,int a, int b ) {
        Calculator c = createCalculator(type, a, b);
        return c;
    }
    protected abstract Calculator createCalculator(Calculator.TYPE type, int a, int b);
}

CalculatorFactory 클래스

Factory 클래스를 상속 받으며 createCalculator() 메소드를 재정의해 실제 인스턴스를 생성해서 '제품을 만드는 일'을 담당하고 있습니다.

public class CalulatorFactory extends Factory {
    @Override
    protected Calculator createCalculator(Calculator.TYPE type,int a, int b) {
        switch(type) {
        case SUM : 
            return new SumCalculator(a, b);
        case DIV : 
            return new DivCalculator(a, b);
        case MUL : 
            return new MulCalculator(a, b);
        }
        return null;
    }
}

Calculator 클래스

제품에 대한 정의로 구현은 하위 클래스에게 위임합니다.

public abstract class Calculator {
    public enum TYPE {
        DIV, SUM, MUL
    }
    public abstract void getValue();
}

SumCalculator 클래스

CalCulator 클래스를 상속받으며 getValue()메소드를 재정의합니다.

public class SumCalculator extends Calculator{
    private int a;
    private int b;

    public SumCalculator(int a, int b) {
        System.out.println("덧셈 계산기의 입력 값은 : " + a + " / " + b + " 입니다");
        this.a = a;
        this.b = b;
    }
    @Override
    public void getValue() {
        System.out.println("연산 결과 : " + ( a + b));
    }
}

DivCalculator 클래스, MulCalculator 클래스

전체적인 로직은 SumCalCulator클래스와 같으나 재정의 하는 getValue()메소드 부분이 다르게 정의되어 있습니다.

// DivCalculator 클래스
@Override
public void getValue() {
    System.out.println("연산 결과 : " + ( a - b));
}

// MulCalculator 클래스
@Override
public void getValue() {
    System.out.println("연산 결과 : " + ( a * b));
}

Main 클래스

실행로직 클래스입니다. 계산기를 만들어서 사용해 보겠습니다.

public class Main {
    public static void main(String[] args) {

        Factory factory = new CalculatorFactory();

        Calculator sumCalculator = factory.create(Calculator.TYPE.SUM, 5, 3);
        sumCalculator.getValue();

        Calculator divCalculator = factory.create(Calculator.TYPE.DIV, 5, 3);
        divCalculator.getValue();

        Calculator mulCalculator = factory.create(Calculator.TYPE.MUL, 5, 3);
        mulCalculator.getValue();

    }
}

실행 결과

덧셈 계산기의 입력 값은 : 5 / 3 입니다
연산 결과 : 8
뺄셈 계산기의 입력 값은 : 5 / 3 입니다
연산 결과 : 2
곱셈 계산기의 입력 값은 : 5 / 3 입니다
연산 결과 : 15

그렇다면 사용하는 이유는 무엇일까?

framework의 수정없이 새로운 '공장'과 '제품'추가가 가능합니다. ( 결합도가 낮다 )
- 전혀 다른 '공학용 계산기'의 제품과 '공학용 계산기 공장'을 해당 framework에 추가해도 해당 클래스들의 내용의 추가만 있을 뿐, 기존 코드에 수정이 필요가 없습니다. 즉 결합도를 낮춰 유지보수에 용이합니다.

단점

패턴을 구현하기 위해 새로운 서브 클래스를 계속 생성하므로, 더 복잡해질 수 있다.

추가 내용

별도로 위 본문에서는 인스턴스 생성을 abstract Method 즉 추상 메소드로 구현을 하위 클래스에게 강제화 시켰지만,
디폴트로 구현을 하고, 재정의 하지 않을 경우 디폴트가 실행되게 하는방법과, 디폴트 시 에러를 발생 시키는 방법 등이 추가로 존재합니다.

default 구현 방식

Class Factory {
    protected Calculator createCalculator(Calculator.TYPE type,int a, int b) {
        // 필요한 로직 작성 ex) return new SumCalculator();
    }
}

에러발생 구현 방식

Class Factory {
    protected Calculator createCalculator(Calculator.TYPE type,int a, int b) {
        throw new FactoryMethodRuntimeException();
    }
}

4. 관련 패턴

Template Method 패턴 : 팩토리 메소드 패턴은 Template Method 패턴의 응용 버전입니다. 본문 create() 메소드 link
Singleton 패턴 : 보통 Creator역할 또는 ConcreteCreator을 수행 하는 클래스는 대부분 복수로 존재할 필요가 없기 때문에 Singleton 패턴으로 만들 수 있습니다. 단, 본문 예제에서는 사용하지 않았습니다. link
Composite 패턴 : Product 역할에 적용 가능합니다.
Iterator 패턴 : 해당 패턴의 iterator() 가 인스턴스를 작성할 때 Factory Method패턴이 사용되는 경우가 존재합니다 link