0117 - 0123

0117 - GRASP 객체지향 설계기법

GRASP Pattern(General Responsibility Assignment Software Patterns)이란?

• Object-Oriented 디자인의 핵심은 각 객체에 책임을 부여하는 것
• 책임을 부여하는 원칙들을 말하고 있는 패턴

구체적인 구조는 없지만, 철학을 배울 수 있다.
총 9가지의 원칙을 가지고 있다.

1. High Cohesion(의존성 높게, 즉 높은 응집력)

• 각 객체가 밀접하게 연관된 책임들만 가지도록 구성.
• 한 객체, 한 시스템이 자기 자신이 부여받은 책임만을 수행하도록 짜임새 있게 구성
• 자신이 부여 받은 책임을 충족시키기 위해 다른 객체나 시스템을 참조하는 일이 적으며 자연스럽게 Low Coupling이 된다.

2. Low Coupling(의존성 낮게)

• 객체들간, 서브 시스템들간의 상호의존도가 낮게 책임을 부여
• 각 객체, 서브시스템의 재 사용성을 높이고, 시스템 관리에 편하게 한다.
• Object-Oriented 시스템은 각 객체들간의 Communication을 통하여 비즈니스를 완성시킴.
• 각 객체들 사이에 Coupling이 존재하지 않을 수는 없다.

3. Information Expert!***

• 책임을 수행할 수 있는 데이터를 가지고 있는 객체에 책임을 부여한다.
• 객체는 데이터와 처리로직이 함께 묶여 있는 것.
• 정보 은닉을 통해 자신의 데이터를 감추고 오직 Method로만 데이터를 처리하고, 외부에는 그 기능(책임)만을 제공한다.

4. Polymorphism(다형성)

• 객체의 종류에 따라 행동양식이 바뀐다면, Polymorphism 기능을 사용
• 만약 객체의 종류에 따라 행동이 바뀐다면 객체의 종류를 체크하는 조건물을 사용하지 말고 Object-Oriented 시스템의 Polymorphism 기능을 사용하라.

5. Pure Fabrication

• 도메인에 관련된 문제를 대표하는 것이 아니라면 기능적인 책임을 별도로 한 곳으로 관리하는 객체를 만든다.
• 데이터베이스 정보를 저장하거나, 로그 정보를 기록하는 책임에 대해 생각해 보자. 각 정보는 각각의 객체들이 가지고 있을 것이다.
• 시스템 전반적으로 사용하고 있는 기능이 있다며, 공통적인 기능을 제고항하는 책임을 한 곳으로 모아서 가상의 객체, 서브시스템을 만들어라.

6. Indirection

• 두 객체 사이의 직접적인 Coupling을 피하고 싶으면, 그 사이에 다른 매개체를 통해 전달하는 것.
• 주로 다른 매개체는 인터페이스인 경우가 많다.
  • 그런 특별한 경우는 아래에 설명된 Protected Variations 패턴이라고 부를 수 있다.

7. Protected Variations

• 변경될 여지가 있는 곳에 안정된 인터페이스를 정의해서 사용하자.

8. Creator

• 객체의 생성은 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여.
• Factory Pattern

9. Controller

• 시스템 이벤트(사용자 요청)를 처리할 객체르 만들자.

0118 - @Sql 애너테이션

@Sql

테스트 클래스나 ㅌ테스트 메서드에 부탁하는 에너테이션이며, 지정된 특정 SQL 스크립트 혹은 Statement를 수행시킨다. 통합테스트에서 편리하게 DB 스키마 생성과 초기 데이터 삽입 및 데이터 초기화 등을 수행할 수 있다.

• 사용 예제

@Sql("classpath:/truncate.sql")
@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = AppConfig.class)
public class SqlTest {
    //...
}

• 각각의 테스트 메서드 실행 전 @Sql 에너테이션이 지정한 스크립트를 실행한다.
• excutionPhase로 스크립트의 실행 시점을 조정할 수 있으며, 기본값은 BEFORE_TEST_METHOD다.
• @Sql({"a.sql", "b.sql", "c.sql"}) 과 같이 복수의 스크립트 파일을 지정할 수 있다.

0121 - Java Optional 바르게 쓰기

Optional을 만든 의도

Brian Goetz는 스텍오버플로우에서 Optional을 만든 의도에 대해 다음과 같이 말했다.

… it was not to be a general purpose Maybe type, as much as many people would have liked us to do so. Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent “no result” …
Optional은 많은 사람들이 우리(자바 언어 설계자)에게 기대했던 범용적인 Maybe 타입과는 다르다. 라이브러리 메서드가 반환할 결과값이 ‘없음’을 명백하게 표현할 필요가 있는 곳에서 제한적으로 사용할 수 있는 메커니즘을 제공하는 것이 Optional을 만든 의도였다.

• java9 API Note

API Note: Optional is primarily intended for use as a method return type where there is a clear need to represent “no result,” and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance.
메서드가 반환할 결과값이 '없음'을 명백하게 표현할 필요가 있고, null을 반환하면 에러를 유발할 가능성이 높은 상황에서 메서드의 반환 타입으로 Optional을 사용하자는 것이 Optional을 만든 주된 목적이다. Optional 타입의 변수의 값은 절대 null 이어서는 안 되며, 항상 Optional 인스턴스를 가르켜야 한다.

올바른 사용법 (java8 기준)

1. isPresent()-get() 대신 orElse()/orElseGet()/orElseThrow()

비싼 Optional을 사용할 경우 코드라도 줄여야 한다.

// 안 좋음
Optional<Member> member = ...;
if (member.isPresent()) {
    return member.get();
} else {
    return null;
}

// 좋음
Optional<Member> member = ...;
return member.orElse(null);



// 안 좋음
Optional<Member> member = ...;
if (member.isPresent()) {
    return member.get();
} else {
    throw new NoSuchElementException();
}

// 좋음
Optional<Member> member = ...;
return member.orElseThrow(() -> new NoSuchElementException());

2. orElse(new ...) 대신 orElseGet(() -> new ...)

orElse(...)에서 ...는 Optional에 값이 있든 없든 무조건 실행된다. 따라서 ...가 새로운 객체를 생성하거나 새로운 연산을 수행하는 경우에는 orElse() 대신 orElseGet()을 사용한다. orElseGet(Supplier)에서 Supplier는 Optional에 값이 없을 때만 실행된다. 따라서 Optional에 값이 없을 때만 새 객체를 생성하거나 새 연산을 수해아므로 불필요한 오버헤드가 없다.

// 안 좋음
Optional<Member> member = ...;
return member.orElse(new Member());  // member에 값이 있든 없든 new Member()는 무조건 실행됨

// 좋음
Optional<Member> member = ...;
return member.orElseGet(Member::new);  // member에 값이 없을 때만 new Member()가 실행됨

// 좋음
Member EMPTY_MEMBER = new Member();
...
Optional<Member> member = ...;
return member.orElse(EMPTY_MEMBER);  // 이미 생성됐거나 계산된 값은 orElse()를 사용해도 무방

3. 단지 값을 얻을 목적이라면 Optional 대신 null 비교

Optional은 비싸다. 따라서 단순히 값 또는 null을 얻을 목적이라면 Optional 대신 null 비교를 사용한다.

// 안 좋음
return Optional.ofNullable(status).orElse(READY);

// 좋음
return status != null ? status : READY;

4. Optional 대신 비어있는 컬렉션 반환

Optional은 비싸다. 그리고 컬렉션은 null이 아니라 비어있는 컬렉션을 반환하는 것이 좋을 때가 많다. 따라서 컬렉션은 Optional로 감싸서 반환하지 말고 비어있는 컬렉션을 반환한다.

// 안 좋음
List<Member> members = team.getMembers();
return Optional.ofNullable(members);

// 좋음
List<Member> members = team.getMembers();
return members != null ? members : Collections.emptyList();

// 안 좋음
public interface MemberRepository<Member, Long> extends JpaRepository {
    Optional<List<Member>> findAllByNameContaining(String part);
}

// 좋음
public interface MemberRepository<Member, Long> extends JpaRepository {
    List<Member> findAllByNameContaining(String part);  // null이 반환되지 않으므로 Optional 불필요
}

5. Optional을 필드로 사용 금지

Optional은 필드에 사용할 목적으로 만들어지지 않았으며, Serializable을 구현하지 않았다. 따라서 Optional은 필드로 사용하지 말자.

// 안 좋음
public class Member {

    private Long id;
    private String name;
    private Optional<String> email = Optional.empty();
}

// 좋음
public class Member {

    private Long id;
    private String name;
    private String email;
}

6. Optional을 생성자나 메서드 인자로 사용 금지

Optional을 생성자나 메서드 인자로 사용하면, 호출할 때마다 Optional을 생성해서 인자로 전달해줘야 한다. 하지만 호출되는 쪽, 즉 api나 라이브러리 메서드에서는 인자가 Optional 이든 아니든 null 체크를 하는 것이 언제나 안전하다. 따라서 굳이 비싼 Optional을 인자로 사용하지 말고 호출되는 쪽에 null 체크 책임을 남겨둔다.

// 안 좋음
public class HRManager {
    
    public void increaseSalary(Optional<Member> member) {
        member.ifPresent(member -> member.increaseSalary(10));
    }
}
hrManager.increaseSalary(Optional.ofNullable(member));

// 좋음
public class HRManager {
    
    public void increaseSalary(Member member) {
        if (member != null) {
            member.increaseSalary(10);
        }
    }
}
hrManager.increaseSalary(member);

7. Optional을 컬렉션의 원소로 사용 금지

컬렉션에는 많은 원소가 들어갈 수 있다. 따라서 비싼 Optional을 원소로 사용하지 말고 원소를 꺼낼때나 사용할 때 null 체크하는 것이 좋다. 특히 Map은 getOrDefault(), putIfAbsent(), computeIfAbsent(), computeIfPresent() 처럼 null 체크가 포함된 메서드를 제공하므로, Map의 원소로 Optional을 사용하지 말고 Map이 제공하는 메서드를 활용하는 것이 좋다.

// 안 좋음
Map<String, Optional<String>> sports = new HashMap<>();
sports.put("100", Optional.of("BasketBall"));
sports.put("101", Optional.ofNullable(someOtherSports));
String basketBall = sports.get("100").orElse("BasketBall");
String unknown = sports.get("101").orElse("");

// 좋음
Map<String, String> sports = new HashMap<>();
sports.put("100", "BasketBall");
sports.put("101", null);
String basketBall = sports.getOrDefault("100", "BasketBall");
String unknown = sports.computeIfAbsent("101", k -> "");

8. of(), ofNullable() 혼동 주의

of(X)는 X가 null이 아님이 확실할 때만 사용해야 하며, X가 null이면 NFE이 발생한다.

// 안 좋음
return Optional.of(member.getEmail());  // member의 email이 null이면 NPE 발생

// 좋음
return Optional.ofNullable(member.getEmail());


// 안 좋음
return Optional.ofNullable("READY");

// 좋음
return Optional.of("READY");

9. Optional 대신 OptionalInt, OptionalLong, OptionalDouble

Optional에 담길 값이 int, long, double이라면 Optional를 사용하면 Boxing/Unboxing이 발생한다.

// 안 좋음
Optional<Integer> count = Optional.of(38);  // boxing 발생
for (int i = 0 ; i < count.get() ; i++) { ... }  // unboxing 발생

// 좋음
OptionalInt count = OptionalInt.of(38);  // boxing 발생 안 함
for (int i = 0 ; i < count.getAsInt() ; i++) { ... }  // unboxing 발생 안 함

0122 - Java Serializable

자바 직렬화

간단하게는 Java 내부 시스템에서 사용되는(또는 JVM 메모리에 올려진) 객체나 데이터를 외부에서 사용할 수 있도록 Byte 형태로 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 기술(역직렬화)을 아울러서 이야기한다.

객체 직렬화는 객체의 상태를 바이트 스트림으로 변환하는데 사용되는 프로세스로, 디스크/파일로 유지되거나 네트워크 동신을 통해 실행중인 다른 Java 가상머신으로 전송될 수 있다. 역직렬화란 이러한 바이트 스트림을 다시 객체형태로 변환하는 작업을 말한다. 생성된 바이트는 플랫폼에 독립적이다.

• 예제

import java.io.Serializable;

public class Member implements Serializable {

    private String name;
    private String email;
    private int age;

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

    @Override
    public String toString() {
        return String.format("Member{name='%s', email='%s', age='%s',", name, email, age);
    }
}

• 직렬화 및 역직렬화 방법

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.Base64;

// ObjectOutputStream 객체와 ObjectInputStream 객체를 사용
public class ObjectSerializableExam{

    public static void main(String[] args) throws Exception {
        Member member = new Member("임준영", "a790077714@gmail.com", 30);
        byte[] serializedMember;

        try(ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
            try(ObjectOutputStream oos = new ObjectOutputStream(baos)) {
                oos.writeObject(member);
                // 직렬화된 member 객체
                serializedMember = baos.toByteArray();
            }
        }
        // base64로 인코딩한 문자열
        String base64Member = Base64.getEncoder().encodeToString(serializedMember);

        // base64로 디코딩한 문자열
        byte[] deserializedMember = Base64.getDecoder().decode(base64Member);

        try(ByteArrayInputStream bais = new ByteArrayInputStream(deserializedMember)) {
            try(ObjectInputStream ois = new ObjectInputStream(bais)) {
                Object objectMember = ois.readObject();
                // member 객체로 역직렬화
                Member readMember = (Member) objectMember;
                System.out.println(member);
            }
        }
    }

• 문자 형태의 직렬화 방법
  직접 데이터를 문자열 형태로 확인 가능한 직렬화 방법. 범용적인 API나 데이터를 변환하여 추출할 때 많이 사용. 표형태의 다량의 데이터를 직렬화시 CSV가 많이 쓰이고 구조적인 데이터는 이전엔 XML 최근에는 JSON을 많이 사용한다.

serialVersionUID 사용 시 주의할점

serialVersionUID는 Java 직렬화 및 역지렬화 할때 필요한 버전 정보이다. 만약 객체를 직렬화하고 클래스에 멈버변수가 추가된다면 java.io.InvalidClassException 예외가 발생한다. Java 직렬화 스펙을 살펴보면 다음과 같다.

• serialVersionUID은 필수 값은 아니다.
• 호환 가능한 클래스는 serialVersionUID 값이 고정되어 있다.
• serialVersionUID가 선언되어 있지 않으면 클래스의 기본 해쉬값을 사용한다.

위의 스펙을 살펴보면 변경에 취약한 클래스가 변경되면 역직렬화 시에 예외가 발생할 수 있으니 개발자가 serialVersionUID 값을 직접 관리해주어야 혼란을 줄일 수 있다는 것을 의미한다. 하지만 그럼에도 불구하고 다른 문제가 발생할 수 있다. 만약 기존의 직렬화된 객체의 멤버 변수의 타입이 바뀐다면 마찬가지로 예외가 발생한다. 이걸 보면 Java직렬화는 상당히 타입에 엄격하다는 것을 확인할 수 있다. 즉, 특별한 문제가 없으면 Java 직렬화 버전 SerialVersionUID 값은 개발 시 직접 관리해줘야 한다. 값이 동일하다면 멤버 변수 및 메서드 추가는 크게 문제가 되지 않으며 멤버 변수 제거 및 이름 변경은 오류는 발생하지 않고 데이터가 누락된다.

결론

최근에는 Json형태로 데이터를 저장하는 경우가 많아서 직렬화를 잘 사용하지 않는데 Json형태로 저장하는 것은 Class에서 취득할 수 있는 부분까지 저장하는 것이고 private까지 저장하는 것은 아니다.