oliver-DevLog

[Effective Java-ITEM 2] Builder

올리버 — Mon, 26 Sep 2022 07:27:26 +0900

Builder 이전의 생성 방식

점층적 생성자 패턴

정적 팩토리 메소드나 생성자의 경우 파라미터가 많은 경우 적절히 대응하기가 쉽지 않다.

다음은 생성자 또는 정적 팩토리 메소드에서 사용했던 점층적 생성자 패턴이다.

public class Car{
    private final int type;
	private final int doors;
    private final int oilType;
    
    public Car(int type){
    	this(type, 4);
    }
    
    public Car(int type, int doors){
    	this(type, doors, 0);
    }
    
    public Car(int type, int doors, int oilType){
    	this.doors = doors;
        this.type = type;
        this.oilType = oilType;
    }
}

해당 클래스의 인스턴스를 생성할 때 필요한 파라미터를 포함한 생성자를 선택해서 호출하면 된다.

점층적 생성자 패턴은 불필요한 변수를 내부에서 설정하기 때문에 그리 나빠보이진 않겠지만, 파라미터가 늘어나면 클라이언트 코드를 작성하거나 읽기 어려워진다.

몇번째 변수가 어떤 값에 해당하는지 주의해야하고 원하는 생성자를 생성했는지 파라미터의 개수도 세어보아야한다.

자바빈즈 패턴

선택해야할 파라미터가 많은 경우 활용할 수 있는 자바빈즈 패턴이 있다.

파라미터가 없는 생성자를 생성 후, Setter 메소드를 호출하여 원하는 값을 직접 설정하는 방식이다.

public Car{
	private int type;
    private int doors = 4; //필수값 설정
    private int oilType;
    
    public Car(){}
    
    public void setType(int type){
    	this.type = type;
    }
    
    public void setDoors(int doors){
    	this.doors = doors;
    }
    
    public void setOilType(int oilType){
    	this.oilType = oilType;
    }
    
    public int getType(){
    	return type;
    }
    public int getDoors(){
    	return doors;
    }
    public int getOilType(){
    	return oilType;
    }
}

Setter메소드를 활용하게 되면 점층적 생성자 패턴에서 나타나던 단점이 사라진다.

직접 Setter를 호출하면서 필요한 값을 설정하면 되기 때문에 어떤 값을 설정하는지 혼동되지 않는다.

하지만 객체 하나를 만들기 위해선 메소드를 여러번 호출해야하고, 객체가 생성되기 전까지는 일관성이 무너진 상태에 노이게 된다.(런타임에 버그로 나타날 수 있다.) 또한 자바빈즈 패턴은 클래스를 불변하게 만들 수 없다.

빌더 패턴

빌더 패턴의 경우 점층적 생성자 패턴의 안정성과 자바빈즈 패턴의 가독성을 가졌다.

사용 방법은 다음과 같다.

1. 필수 파라미터만으로 생성자 또는 정적 팩토리 메소드를 호출해 빌더 객체를 얻는다.

2. 빌더 객체가 제공하는 일종의 Setter 메소드로 원하는 파라미터를 설정한다.

3. 파라미터가 없는 build()를 호출하여 필요한 객체를 얻는다.(보통 불변 객체이다.)

빌더는 생성할 클래스 안에 정적 멤버 클래스로 만들어두는게 보통이다.

//import 있다고 가정
enum CarType{SEDAN,SUV,CUV,SPORT,TRUCK}
enum OilType{GASOLINE,DIESEL,LPG}

public class Car{
	private final CarType type;
	private final int doors;
	private final OilType oilType;

	public static class Builder{
		//필수 파라미터
		private final CarType type;

		//선택 파라미터의 경우 Default 값으로 셋팅
		private int doors = 4;
		private OilType oilType = OilType.GASOLINE;

		public Builder(CarType type){
			this.type = type;
		}

		public Builder doors(int val){
			this.doors = val;

			return this;
		}

		public Builder oilType(OilType val){
			this.oilType = val;

			return this;
		}

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

빌더의 Setter 메소드들은 자기 자신을 반환하기 때문에 연쇄적 호출을 할 수 있다.

이런 방식을 Fluent API 또는 Method Chaining 이라고 한다.(메소드 호출이 흐르듯 연결된다는 뜻)

해당 빌더를 사용하는 클라이언트 코드는 다음과 같다.

예시로 세단 형태의 3개의 문을 가진 디젤 차량을 생성한다.

Car car = new Car.Builder(CarType.SEDAN)
                 .doors(3)
                 .oilType(OilType.DIESEL)
                 .build();

현재 유효성 검사 로직은 제거하였지만, 필요하다면 유효성 검사 로직을 추가하여 잘못된 점을 발견하게 되면 메세지를 담아 IllegalArgumentException 을 던져주면 된다.

추상 클래스를 활용한 빌더

빌더 패턴은 계층적으로 설계된 클래스와 사용하기 좋다.

추상클래스의 경우 추상 빌더, Concrete 클래스의 경우 Concrete 빌더를 갖게 한다.

다음은 추상 클래스를 활용한 추상 빌더 구현한 코드이다.

abstract class Burger{
	public enum Topping{CHEEZE,PATTY,LETTUCE, TOMATO,MUSGROOM, ONION, PICKLE, EGG}
	final Set<Topping> toppings;

	abstract static class Builder<T extends Builder<T>>{
		EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);

		protected abstract T self();

		public T addTopping(Topping topping){
			toppings.add(topping);
			return self();
		}

		public abstract Burger build();
	}

	protected Burger(Builder<?> builder){
		toppings = builder.toppings.clone();
	}
}

다음은 Burger 추상 클래스를 상속 받은 EggSlut 클래스를 생성해보겠다.

class EggSlut extends Burger{
	public enum Side{NONE, FRENCH_FRIES, SLUT, COLA}
	private final Side side;

	public static class Builder extends Burger.Builder<Builder>{
		private final Side side;

		@Override
		protected Builder self(){
			return this;
		}

		public Builder(Side side){
			this.side = Objects.requireNonNull(side);
		}

		@Override
		public EggSlut build(){
			return new EggSlut(this);
		}
	}

	public EggSlut(Builder builder){
		super(builder);
		side = builder.side;
	}
}

EggSlut 인스턴스를 가지려면 동일하게 Builder를 호출하여 사용하면 된다.

EggSlut eggSlut = new EggSlut.Builder(EggSlut.Side.SLUT)
                             .addTopping(Burger.Topping.EGG)
                             .addTopping(Burger.Topping.LETTUCE)
                             .addTopping(Burger.Topping.CHEEZE)
                             .addTopping(Burger.Topping.TOMATO)
                             .build();

위 코드를 보다시피 빌더 패턴은 매우 유연하다.

빌더 하나로 여러 객체를 만들 수 있고, 넘겨지는 파라미터에 따라 다른 객체를 만들 수 도 있다.

빌더 패턴의 단점이 있다면

빌더 생성 비용은 크진 않지만, 성능에 민감한 서비스라면 문제가 될수 있다.

코드가 장황하다 보니 파라미터가 4개 이상 되어야 값어치를 한다.

다만 API는 시간이 지날 수록 파라미터가 많아지는 경향이 있으니 예방차원에서 빌더를 구현해도 좋다.

[Effective Java-ITEM 1] 정적 팩토리 메소드

올리버 — Thu, 15 Sep 2022 21:52:24 +0900

전통적인 인스턴스 생성 방법

클래스의 인스턴스 생성 방식 중에 흔히 사용 하는 것이 public 생성자이다.

생성자를 통해 인스턴스를 생성하여 사용하게 되면 어떤 것을 반환하고자 하는지 찾기가 모호해질 수 있다.

class Pizza{
	private final String cheese;
	private final String topping;
	private final int size;

	public Pizza(String cheese, String topping, int size){
		this.cheese = cheese;
		this.topping = topping;
		this.size = size;
	}
    
    ...
}

위의 코드를 보면 Pizza 인스턴스를 생성하려면 다음과 같이 생성해야한다.

Pizza cheesePizza = new Pizza("체다치즈","토마토소스",10);

만약 파라미터가 더욱더 많아지게 된다면 해당 순서의 파라미터가 무슨 일을 하는 것인지 구분하기가 어려워지게 되고, 개발자 또한 실수를 범하게 될수 있다.

정적 팩토리 메소드

정적 팩토리 메소드는 객체를 생성을 담당하는 클래스 메소드이다.

전통적인 생성 방식과 다른 점은 new를 할때 직접적으로 하는 것이 아닌 메소드를 통해 간접적으로 생성하게 된다.

//생성자 방식
String constructorStr = new String("Constructor");

//정적 팩토리 메소드 방식
String factoryStr = String.valueOf("Factory");

이런 정적 팩토리 메소드는 다음과 같은 장단점을 가지게 된다.

장점

1. 이름을 가질 수 있다.

생성자의 파라미터로는 해당 인스턴스가 어떤 역할을 하는지 특성을 제대로 설명하지 못한다.

반면 정적 팩토리 메소드는 네이밍만 올바르게 한다면 반환할 인스턴스의 특정을 제대로 설명할 수 있다.

class Pizza{
	private final String cheese;
	private final String topping;
	private final int size;

	public Pizza(String cheese, String topping, int size){
		this.cheese = cheese;
		this.topping = topping;
		this.size = size;
	}

	public static Pizza cheesePizza(int size){
		return new Pizza("체다치즈", "토마토소스", size);
	}

	public static Pizza peperoniPizza(int size){
		return new Pizza("기본치즈", "페퍼로니", size);
	}
}

//생성자 방식
Pizza cheesePizza = new Pizza("체다치즈","토마토소스",10);

//정적 팩토리 메소드
Pizza cheesePizza = Pizza.cheesePizza(10);

2. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.

정적 팩토리 메소드를 사용하게 되면 미리 만들어진 인스턴스를 캐싱하여 재활용하는 식으로 사용하여 무분별한 객체 생성을 막을 수있다.

Boolean vlaue = Boolean.valueOf(true);

위와 같이 Boolean 객체를 new 하여 인스턴스화하지 않고 받아올 수 있다.

이렇게 미리 만들어진 객체를 사용하게 되면 인스턴스가 단 하나 뿐임을 보장할 수 있다.

3. 반환 타입의 하위 타입 인스턴스를 반환 할수 있다.

이 능력으로 반환할 객체의 클래스를 자유롭게 선택할 수 있는 유연성을 제공한다.

class Mobility{
	public static Mobility of(String type){
		if(type.equalsIgnoreCase("car")){
			return new Car();
		}else if(type.equalsIgnoreCase("bike")){
			return new Bike();
		}
        ...
	}
}

위 클래스를 보면 of 메소드를 통해 type 별로 필요한 모빌리티를 반환해준다.

4. 입력 파라미터에 따라 매번 다른 클래스의 인스턴스를 반환한다.

반환 타입의 하위 타입이기만 하면 어떤 클래스를 반환하든 상관없다.

Java의 EnumSet클래스가 그 예가 될 수 있다.

아래 코드를 보면 파라미터 길이에 따라 다른 클래스를 반환하고 있다.

public static <E extends Enum<E>> EnumSet<E> noneOf(Class<E> elementType) {
    Enum<?>[] universe = getUniverse(elementType);
    if (universe == null)
        throw new ClassCastException(elementType + " not an enum");

    if (universe.length <= 64)
        return new RegularEnumSet<>(elementType, universe);
    else
        return new JumboEnumSet<>(elementType, universe);
}

5. 정적 팩토리 메소드를 작정하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

이 유연함을 통해 서비스 제공자 프레임워크를 만들 수 있었다.

클래스가 존재해야 생성자가 존재할 수 있지만, 정적 팩토리 메소드는 메소드와 반환할 타입만 정해두고 실제 반환될 클래스를 나중에 구현하는게 가능하다.

private Class<?> serviceClass(){
    return Class.forName("com.test.services.TestService");
}

단점

1. 정적 팩토리 메소드만 제공하는 경우에는 상속이 불가능하다.

상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩토리 메소드만 제공하면 하위 클래스를 생성할 수 없다.

2. 개발자가 찾기 어렵다.

API설명에 명확히 드러나지 않다보니 다른 개발자가 찾기 어렵다.

하지만 문서화를 잘하고, 메소드 네이밍을 널리 알려진 규약으로 사용한다면 문제를 완화할 수 있다.

Collection Interface로 업캐스팅을 하는 이유

올리버 — Thu, 26 May 2022 10:37:02 +0900

List, Set, Map을 사용하다보면 습관적으로 List 리스트= new ArrayList처럼 사용하게 된다.

하지만 구현체를 직접 선언하여 ArrayList 리스트 = new ArrayList로 사용하게된다면 다음과 같은 린트(Lint) 메시지를 확인 할 수 있다.

Declarations should use Java collection interfaces such as "List" rather than specific implementation classes such as "LinkedList"

The purpose of the Java Collections API is to provide a well defined hierarchy of interfaces in order to hide implementation details.

Implementing classes must be used to instantiate new collections, but the result of an instantiation should ideally be stored in a variable whose type is a Java Collection interface.

This rule raises an issue when an implementation class:

is returned from a public method.
is accepted as an argument to a public method.
is exposed as a public member.

Noncompliant Code Example

public class Employees {
  private HashSet<Employee> employees = new HashSet<Employee>();  // Noncompliant - "employees" should have type "Set" rather than "HashSet"

  public HashSet<Employee> getEmployees() {                       // Noncompliant
    return employees;
  }
}

Compliant Solution

public class Employees {
  private Set<Employee> employees = new HashSet<Employee>();      // Compliant

  public Set<Employee> getEmployees() {                           // Compliant
    return employees;
  }
}

먼저 List, Set, Map은 Interface이다.

그리고 각각의 구현체로는 ArrayList, LinkedList, HashSet, HashMap 등등 존재한다.

왜 굳이 구현체로 선언하지않고 Interface로 업캐스팅할까?

다형성을 지원하기 위해서이다.

유연한 구조로 설계하여서 나중에 다른 구현체로 변경할때 쉽게 변경하기 위해서 사용한다.

즉 업캐스팅으로 선언하면 모든 코드가 해당 Interface를 따르게 코드를 작성할 수 있고, 해당 Interface를 구현한 다른 자료형 간 쉽게 변경이 된다.

잘못 사용된 예

//구현체를 직접 사용하는 경우
ArrayList<String> list = new ArrayList<>();
HashMap<String,Object> map = new HahMap<>();
HashSet<String> set = new HashSet<>();

public void methodName(HashMap<String,Object> param){
    ....
}

올바른 예

//Interface로 업캐스팅하여 사용하는 경우
List<String> list = new ArrayList<>();
Map<String,Object> map = new HahMap<>();
Set<String> set = new HashSet<>();

public void methodName(Map<String,Object> param){
    ....
}

참고

https://stackoverflow.com/questions/9852831/polymorphism-why-use-list-list-new-arraylist-instead-of-arraylist-list-n

Polymorphism: Why use "List list = new ArrayList" instead of "ArrayList list = new ArrayList"?

Possible Duplicate: Why should the interface for a Java class be prefered? When should I use List<Object> list = new ArrayList<Object>(); ArrayList inherits from List, so if some

stackoverflow.com

Try-With-Resources를 이용한 자원 반납

올리버 — Wed, 25 May 2022 00:19:13 +0900

Java7 이전에는 자원을 해제 하기 위해서 try-catch-finally를 사용하여 자원을 해제했다.

BufferedReader br = null;

try{
    br = new BufferedReader(new InputStreamReader(System.in));
    String str = br.readLine();
    
    System.out.println(str);
}catch(IOException e){
	e.printStackTrace();
}finally{
    if(br != null{
        try{
            br.close();
        }catch(Excetpion e){}
    }
}

Java7 이후에 생긴 기능 중 하나인 try-with-resources는 try 구문에서 자원을 생성하고 사용을 완료하면 자동 반납(Close)해주는 기능이다.

java.lang 패키지의 AutoCloseable 인터페이스를 상속받으면 try구문에서 자원을 생성할 수 있고, 사용을 완료하면 자동 반납하게 된다.

try-with-resources 자원 사용/반납하기

기존에 finally에서 close를 직접 해주었다면 try-with-resources를 사용하여 조금더 간결해진 코드를 확인 할 수 있다.

try 구문 옆에 생성하고 사용이 완료되면 자동으로 반납이 된다.

try(BufferedReader br = new BufferedReader(new InputStreamReader(System.in))){
    String str = br.readLine();
    
    System.out.println(str);
}catch(IOException e){
	e.printStackTrace();
}

여러개의 자원을 할당하려면 ;(세미콜론)을 붙여서 작성하면 된다.

여러개를 할당하게 되면 위에서 Top-Down으로 생성되지만, 해제는 Bottom-Up 순서로 해제가 된다.

try(BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out))){
    String str = br.readLine();
    
    bw.write(str);
    bw.newLine();
    bw.flush();
}catch(IOException e){
	e.printStackTrace();
}

AutoCloseable 상속

AutoCloseable을 상속받아서 클래스를 커스터마이징하여 사용할 경우 동일하게 자원 반납을 자동으로 해줄수 있다.

class CloseableResource implements AutoCloseable{

    private String name;
    
    public CloseableResource(String name){
        this.name = name;
        System.out.println("Created Resource : " +name);
    }

    public void useResource(){
        System.out.println("Using this Resource : " +name);
    }

    @Override
    public void close() throws Exception {
        System.out.println("Close Resource : "+ name);        
    }
}

public class Main{
    public static void main(String[] args){
        try(CloseableResource resource = new CloseableResource("customObject")){
            resource.useResource();
        }catch(Exception e){
            e.printStackTrace();
        }
    }
}

#실행 결과
Created Resource : customObject
Using this Resource : customObject
Close Resource : customObject

자원을 여러개 할당할 경우 다음과 같이 나타나게 된다.

해제 시 Bottom-Up 순서로 나타난다.

public class Main{
    public static void main(String[] args){
        try(CloseableResource object1 = new CloseableResource("object1");
            CloseableResource object2 = new CloseableResource("object2")){
            object1.useResource();
            object2.useResource();
        }catch(Exception e){
            e.printStackTrace();
        }
    }
}

#실행결과
#생성은 Top-Down
#반납은 Bottom-Up
Created Resource : object1
Created Resource : object2   
Using this Resource : object1
Using this Resource : object2
Close Resource : object2     
Close Resource : object1

[Spring Boot] DI(의존성 주입)

올리버 — Tue, 24 May 2022 11:27:36 +0900

Spring의 핵심 기술중 하나인 DI(의존성 주입)에 대해 알아보자.

필드 주입(Field Injection)

필드 주입은 필드에서 바로 주입하는 방법이다. 과거에 많 이용되었지만 외부에서 접근이 불가능하고, 테스트코드 작성 시 필드의 객체를 수정할 수 없게 되어 사용하지 않게 되었다.

즉 강한 결합으로 인해 외부에서 사용하기가 어려워진다.

//Field Injection
public class MyController{
     @Autowired
     private MyService myService;
}

수정자 주입(Setter Injection)

수정자 주입은 Setter Method을 통해 주입하는 방법이다. 주입 받는 객체가 변경될 가능성이 있는 경우에 사용한다.

의존관계를 나타낼 수 있으나, 필수적으로 주입되어야 할 항목들을 빼먹어 null 처리될 수가 있다.

//Setter Injection
public class MyController{
    private MyService myService;
    
    @Autowired
    public void setMyService(MyService myService){
    	this.myService = myService;
    }
}

생성자 주입(Constructor Injection)

생성자에서 주입하는 방법이다. 최근 Spring에서 권장하는 방법인데 그 이유는 다음과 같다.

1. 객체의 불변성 확보

생성자 주입을 통해 변경 가능성을 배제하고 불변성을 보장한다

2. 테스트 코드 작성 용이

생성자 주입이 아닌 다른 주입으로 작성된 코드는 순수 자바 코드로 테스트 작성하는 것이 어렵다.

//Field Injection
public class MyService{
     @Autowired
     private MyRepository myRepository;
     
     public User findById(String id){
     	return myRepository.findById(id);
     }
}

해당 클래스의 테스트 코드는 다음과 같다.

public class MyServiceTest{
	
    @Test
    public void findByIdTest(){
    	//Given
        MyService myService = new MyService();
        String id = "testId";
        
        //When
        User user = myService.findById(id);
        
        //Then
        assertEquals(user.getId(),id);
    }
}

위와 같이 작성한 경우 DI 프레임워크 위에서 동작하지 않기 때문에 의존 관계가 주입되지 않아 의존성 주입 대상인 myRepository가 null이 되어 findById를 실행할 때 NPE가 발생한다. 수정자 주입을 통해 처리할 수는 있지만, 변경 가능성을 열어두기 때문에 단점을 갖게 된다.

만약 Spring Bean을 올려서 하기위해서는 MockBean으로 생성해서 하거나 SpringBootTest를 통해 전체 테스트를 해야하는데 이것은 단위테스트가 아니기 때문에, 생성자 주입을 사용한다.

또한 생성자 주입을 사용했을 때 컴파일 시점에서 오류를 발견할 수 있다.

3. Final 키워드 작성

생성자 주입을 하게 되면 final 키워드를 사용할 수 있고, 컴파일 단에서 누락된 부분을 확인 할 수 있다.

Spring에서 생성자가 1개인 경우에는 @Autowired를 생략해도 된다.

또는 Lombok의 RequiredArgsConstructor을 활용해도 된다.

따라서 다음과 같이 작성이 가능하다. 다음 3개는 동일한 동작을 하게 된다.

//Constructor Injection
public class MyController{
    private final MyService myService;
    
    @Autowired
    public MyController(MyService myService){
    	this.myService = myService;
    }
}

//Constructor Injection
public class MyController{
    private final MyService myService;
    
    public MyController(MyService myService){
    	this.myService = myService;
    }
}

//Constructor Injection
@RequiredArgsConstructor
public class MyController{
    private final MyService myService;
}

4. 순환 참조 방지

주입하려는 대상이 서로 마주보고 있어 계속해서 참조하고 생성하는 것을 순환 참조라고 한다.

@Component
public class MyServiceA{
    @Autowired
    private MyServiceB myServiceB;
    
    public void startB(){
        myServiceB.startA();
    }
}

@Component
public class MyServiceB{
    @Autowired
    private MyServiceA myServiceA;
    
    public void startA(){
        myServiceA.startB();
    }
}

위와 같은 상황이 발생하게 되면 MyServiceA 가 MyServiceB를 호출하고 MyServiceB가 MyServiceA를 호출하게되는데 해당 객체를 필드 주입 또는 수정자 주입을 통해하게 되면 런타임 중에 계속적으로 new 하게 되어 StackOverFlow가 발생하게 된다.

Caused by: java.lang.StackOverflowError: null

하지만 생성자 주입을 통해 생성하게 되면 다음과 같이 나타난다.

@Component
@RequiredArgsConstructor
public class MyServiceA{
    private final MyServiceB myServiceB;
    
    public void startB(){
        myServiceB.startA();
    }
}

@Component
@RequiredArgsConstructor
public class MyServiceB{
    private final MyServiceA myServiceA;
    
    public void startA(){
        myServiceA.startB();
    }
}

위와 같이 하게 되면 객체가 생성될때 주입을 하게되기 때문에, 애플리케이션 수동 시점에서 순환 참조를 알아차릴 수 있습니다.

Description: 
The dependencies of some of the beans in the application context form a cycle: 
┌─────┐ 
| myServiceA defined in file [.....class]
  ↑ ↓ 
| myServiceB defined in file [.....class]
└─────┘

요약

DI(의존성 주입)을 할때 필드 주입, 수정자 주입 보다 생성자 주입을 하여 사용하여서, 순환 참조를 방지하고,

테스트 코드를 더욱 간편하게 작성할 수 있다.

참고

강한 결합과 약한 결합

올리버 — Wed, 18 May 2022 17:56:24 +0900

강한 결합

어떠한 객체가 다른 객체에 강한 의존성을 가지고 있음을 말한다.

아래의 클래스를 보면 사람이 개를 훈련하다라는 의미를 부여할 수 있다.

public class Dog{
    public void train(){
        System.out.println("train dog");
    }
}

public class Cat{
    public void train(){
        System.out.println("train cat");
    }
}

public class Person{
    private Dog dog;
    
    public Person(){
        dog = new Dog();
    }
    
    public void trainAnimal(){
        dog.train();
    }
}

Person 클래스를 보면 맴버 변수로 Dog 클래스를 가지고 있다. 여기선 단점을 발견 할 수 있다.

Dog 클래스가 없는 경우 Person 클래스는 존재할 수 없다.
Dog 에서 Cat으로 변경하게 되면 Person의 코드를 변경해야한다.

즉, Person 클래스는 Dog 클래스에 의존하게 된다.

약한 결합

객체 간의 의존성을 약하게 하는 것이다.

public interface animal{
    void train();
}

public class Dog implements Animal{
    @Override
    public void train(){
        System.out.println("train dog");
    }
}

public class Cat implements Animal{
    @Override
    public void train(){
        System.out.println("train cat");
    }
}

public class Person{
    private Animal animal;
    
    public Person(Animal animal){
        this.animal = animal;
    }
    
    public void trainAnimal(){
        animal.train();
    }
}

Interface로 추상화하여 개발하게 되면 내부 클래스를 변경하지 않아도, 하나의 인터페이스로 대입되기 때문에, 생성자를 통하거나 수정 메소드를 통해 변수만 받으면 객체 변경이 가능해진다.(런타임 시 의존관계 결정)

즉 강한 결합에서 벗어난 약한 결합을 이룬다.

암호화 알고리즘 종류

올리버 — Mon, 9 May 2022 13:56:22 +0900

정의

평문(Plaintext) - 해독 가능한 형태의 메시지

암호문(Ciphertext) - 해독 불가능한 형태의 메시지

암호화(Encryption) - 평문을 암호문으로 변환하는 과정

복호화(Decryption) - 암호문을 평문으로 변환하는 과정

양방향 암호화

암호화와 복호화 과정을 통해 송, 수신 간 주고받는 메시지를 안전하게 암, 복호화하는 과정이다.

1. 대칭키 암호화

암호화와 복호화 시 같은 키를 사용하며, 계산속도가 빠르다.

종류 : AES128, AES256, SEED(국내 표준)

문제점 : 수신 측에 키를 전달하는 과정에서 유출될 우려가 있다.

2. 비대칭키 암호화

공개키 암호화의 경우

개인키 암호화의 경우

암호화와 복호화 시 서로 다른 키를 사용한다.

공개키(Public Key)와 개인키(Private Key)가 한 쌍으로 이루어지고 있다.

송, 수신자는 개인 별로 공개키와 개인키를 생성한다.

공개키와 개인키는 다음과 같은 특성을 가진다.

A의 공개키를 이용하여 암호화된 데이터는 A의 개인키로만 복호화가 가능하다.

A의 개인키를 이용하여 암호화된 데이터는 A의 공개키로만 복호화가 가능하다.

통신 방식

암호 모드 - 송신자 공개키로 암호화 -> 송신자 개인키로 복호화
소량의 메시지 암호화 목적, 주로 키 교환의 용도로 사용

인증 모드 - 송신자 개인키로 암호화 -> 송신자 공개키로 복호화
메시지를 인증(부인방지)하는 것이 목적

종류 : RSA(대표적 공개키 알고리즘), DSA(전자서명 알고리즘 표준), ECC

단방향 암호화

해싱(Hashing)을 이용한 암호화 방식으로 평문을 암호문으로 암호화는 가능하지만 암호문을 평문으로 복호화하는 것은 불가능하다.

데이터의 진위여부는 확인하고 싶으나, 본 데이터의 Privacy를 지키고 싶은 경우 사용한다.

Hash값은 크기와 알고리즘에 따라 암호문의 결과가 상이하다.

동일한 값이 입력되면 언제나 동일한 출력을 보장한다.

종류 : MD5, SHA-1, SHA,256, SHA-512 등

참고

[Kafka] (2) Topic과 Partition

올리버 — Wed, 23 Mar 2022 20:43:52 +0900

Events, Streams, Topics

Events

Event란, 과거에 일어난 사실을 뜻한다.

Event는 발생함으로 인해 변화된 상태를 가지고 시스템 사이를 오가는 불변의 데이터이다.

Streams

Event Stream이란, 관련된 Event들을 나타낸다.

Topics

Event Stream이 Kafka에서는 Topic이란 이름으로 저장된다.

Kafka에서는 Topic이 구체화된 Event Stream을 뜻한다.

Topic은 데이터베이스의 테이블이나 파일 시스템의 폴더들 같이 연관된 Event를 묶어 영속화한다.

Topic은 Kafka에서 Producer 와 Consumer 를 분리하는 중요한 컨셉이다.

Producer 는 Topic에 Message(Event)를 저장 (Push) 하고 Consumer 는 저장된 Message(Event)를 읽어 (Pull) 온다.

하나의 Topic에 여러 Producer, Consumer 가 존재할 수 있다.

아래 그림을 보면 연관된 Event가 모여 Stream 을 이루게 되고, Topic 의 이름으로 Kafka에 저장된다.

Partitions

Topic은 여러 Partition으로 나눠진다.

Topic이 일종의 논리적인 개념이라면, Partition은 Topic에 속한 레코드를 실제 저장소에 저장하는 가장 작은 단위이다. 각각의 Partition은 Append-Only 방식으로 기록되는 하나의 로그 파일이다.

아래 그림에서 레코드는 Partition에 저장되는 Message를 의미한다.

Offset과 Messages의 순서

Partition의 레코드는 각각 Offset을 가진다.

Offset은 Partition내에서 고유한 레코드의 순서를 의미하는 식별자 정보를 가진다.

Offset 정보는 Kafka에 의해서 관리되고, 값이 계속 증가하며 불변하는 숫자 정보이다.

레코드가 Partition에 쓰여질 때 항상 기록의 맨 뒤에 쓰여지고(Append Only), 다음 순서의 Offset 값을 갖게 된다.

Offset은 Partition에서 레코드를 읽고 사용하는 Consumer 에게 특히 유용하다.

아래의 그림은 세 개의 Partition을 갖는 Topic을 보여준다.

레코드는 각 Partition의 마지막에 추가된다.

Message는 Partition 내에서는 유의미한 순서를 가지고 이를 보장하지만, Partition 간에는 보장되지 않는다.

그래서 Offset이 존재함에도 Message의 순서가 보장되지 않는 것이다.

Partition으로 인한 Kafka의 확장성

Kafka Cluster는 Broker라 불리는 하나 혹은 그 이상의 서버들로 이루어지는데, 각각의 Broker는 전체 클러스터에 속한 레코드의 서브셋을 가진다.

Kafka는 Topic의 Partition들을 여러 Broker에 배포하는데 이로 인해 얻을 수 있는 다음과 같은 이점들이 있다.

한 Topic의 모든 Partition을 하나의 Broker에 넣을 경우,
해당 Topic의 확장성은 Broker의 I/O 처리량에 의해 제약되지만, Partition들을 여러 Broker에 나누면,
하나의 Topic은 수평적으로 확장될 수 있고 이로 인해 Broker의 처리 능력보다 더 큰 성능을 제공할 수 있게 된다.
Topic은 여러 Consumer 에 의해 동시에 처리될 수 있다.
단일 Broker에서 모든 Partition을 제공하면 지원할 수 있는 Consumer 수가 제약되는데,
여러 Broker에서 Partition을 나누어 제공함으로써 더 많은 Consumer 들이 동시에 Message를 처리할 수 있게 된다.
동일한 Consumer 의 여러 인스턴스가 서로 다른 Broker에 있는 Partition에 접속함으로써 매우 높은 메시지 처리량을 가능하게 한다. 각 Consumer 인스턴스는 하나의 Partition에서 Message를 제공받고,
각각의 레코드는 명확한 처리 담당자가 존재함을 보장할 수 있다.

Partition 복제를 통해 장해 극복

Kafka는 여러 Broker에 동일한 Partition의 복사본, 즉 Replica를 2개 이상 유지한다.
Broker에 장애가 발생해도 Replica를 통해 Consumer에게 지속적으로 Message를 제공할 수 있다.

Partition에 레코드 작성하는 방법(Producer)

1. Partition Key 사용

Producer 는 Partition Key를 사용해서 특정한 Partition에 Message를 전달할 수 있다.

Partition Key는 해싱 함수를 통해 전달되고 해싱 함수는 동일한 Key를 갖는 모든 레코드들이 동일한 Partition에 도착하는 것을 보장한다.

Partition Key를 지정할 경우, 관련된 Event를 동일한 Partition에 유지함으로써 전달된 순서가 그대로 유지되는 것을 보장할 수 있다. 다만 Key가 제대로 분산되지 않는 경우 특정 Broker만 Message를 받는 단점이 있다.

2. Kafka에 의한 분배

Producer 가 Partition Key를 명시하지 않으면, Kafka 는 Round-Robin 방식을 사용해 Partition을 배정한다.

레코드의 순서는 보장되지 않지만, 해당 Topic의 Partition들에 고루 분배된다.

3. 커스텀 Partitioner 구현

Producer 가 서로 다른 비즈니스 규칙을 사용한 자체 Partitioner 구현을 사용할 수도 있다.

Partition으로 부터 레코드 읽기(Consumer)

Kafka 는 Message를 Consumer 에 전달(Push) 하지 않고, Consumer 가 Partition으로부터 Message를 읽어(Pull) 가야 한다. Consumer는 Broker의 Partition과 연결해, Message들이 쓰여진 순서대로 메시지를 읽는다.

Message의 Offset 은 커서와 같이 동작한다.

Consumer 는 Message의 Offset으로 커서를 이동하여 Message를 읽는다.(Offset 이동 -> Message 읽기 반복)

각 Partition에서 마지막으로 소비된 Message의 Offset 을 기억함으로써 Consumer는 장애가 나도 복구 후에 Message 소비를 재시작할 수 있다.

Partition은 하나 이상의 Consumer 들로부터 소비될 수 있고, 각각은 서로 다른 Offset 을 가지고 Message를 읽을 수 있다.

Kafka는 Consumer Group 이라는 개념을 사용한다.(어떤 Topic을 소비하는 Consumer 들을 그룹으로 묶은 것)

동일한 Consumer Group 에 있는 Consumer 들은 동일한 Group-Id 를 부여받는다.

Partition 내의 Message는 Group 내의 Consumer 중 하나에 의해서만 소비되는 것을 보장한다.

Consumer Group 은 Consumer 들이 병렬적으로 Message를 소비할 수 있도록 한다.

병렬 처리를 가능케 함으로써 처리량은 매우 높아지지만, Group의 Maximum Parallelism 은 Topic의 Partition 개수와 동일하다.

여기서 중요한 것은, Consumer 의 개수가 토픽의 병렬성 정도를 결정하지 않고, 결정하는 것은 파티션의 개수라는 것이다. 하지만 파티션을 늘리는 것이 항상 장점으로 작용하지는 않는다. 이와 관련해선 차후에 정리하도록하자.

참고

https://kafka.apache.org/documentation/

https://medium.com/event-driven-utopia/understanding-kafka-topic-partitions-ae40f80552e8

https://devidea.tistory.com/95

[Kafka] (1) Kafka란?

올리버 — Sun, 20 Mar 2022 00:24:12 +0900

Kafka란?

Kafka는 Distributed Event Streaming Platform(분산 이벤트 스트리밍 플랫폼)이다.

Publish-Subscribe 모델의 Message Queue이며, 분산에 특화되어 있다.

기본 구조

1.1 Event

Event는 Producer와 Consumer가 데이터를 주고 받는 단위이다.

1.2 Topic

Event가 쓰이는 곳이다.
Topic은 파일시스템의 폴더 또는 디렉토리와 유사하며, 이벤트는 폴더안의 파일과 유사하다.
Topic의 개수는 제한이 없고, 이름으로 구분된다.
Topic이 다시 특정한 개수의 partitions이 된다. 개수의 명시가 필요하다

1.3 Partition

Topic이 나눠지는 단위이다.
Partition에 한 번 쓰여진 데이터는 변경이 불가능 하다.
Topic을 구성하는 Partition은 정렬되어 있지만, 키 값이 제공되지 않으면 랜덤하게 할당한다.
하나의 파티션에 순차적으로 처리하는 것보다 병렬 처리하여 시간을 절약하기 위해 Partition을 나눈다.

1.4 Broker

Kafka 서버를 가르키며 특정한 Topic의 Partition을 보유한다.
3개 이상의 Broker를 가지는 것이 장애 허용 관점에서 좋다.

1.5 Producer

Producer는 Kafka에 Event를 게시하는 클라이언트 어플리케이션이다.

1.6 Consumer

Consumer은 Topic을 구독하고 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션이다.

1.7 Zookeeper

Kafka Cluster 상태를 관리한다.
Broker를 모니터링하고, Topic과 Partition을 관리한다.
Kafka는 Zookeeper없이 실행할 수 없다.

Broker의 디스크 순차 저장 및 처리

Event를 메모리에 저장하는 기존 메시징 시스템과는 달리 Event를 파일 시스템에 저장한다.
파일 시스템에 Event를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durability)이 보장된다.
디스크가 순차적으로 저장되어 있으므로 디스크 I/O가 줄어들어 속도가 빠르다

Pub-Sub모델을 활용한 멀티 Producer, Consumer

Event를 보내는 역할(Producer)과 받는 역할(Consmer)이 완벽하게 분리되어 있다.
느슨한 결합을 통해 어느 한쪽 시스템에서 문제가 발생하더라도 서로 의존성이 없으므로 연쇄작용이 발생할 확률은 매우 낮다.
하나의 Topic에 여러 Producer 또는 Consumer들이 접근 가능한 구조로 되어 있다.
그렇기 때문에 하나의 Producer가 하나의 Topic에만 Event를 보내는 것이 아닌 하나 이상의 Topic으로 보내고, Consumer는 하나 이상의 Topic으로 부터 Event를 가져온다.

확장성

하나의 Kafka Cluster는 3대의 Broker로 시작해 수십대의 Broker로 확장 가능하다.
온라인 상태에서 무중단 확장이 가능하다.

먼저 Kafka의 구성 요소와 가장 큰 특징인 디스크 처리와 pub-sub 모델을 알아보았다.

다음 장에서 Topic에 대해 알아보자

참고

https://kafka.apache.org/documentation/#gettingStarted

https://www.tibco.com/ko/reference-center/what-is-apache-kafka

https://velog.io/@busybean3/%EC%95%84%ED%8C%8C%EC%B9%98-%EC%B9%B4%ED%94%84%EC%B9%B4Apache-Kafka%EC%9D%98-%ED%8A%B9%EC%A7%95-3

https://velog.io/@qlgks1/0%EC%9E%A5.-%EC%B9%B4%ED%94%84%EC%B9%B4Kafka%EB%9E%80

curl명령어로 HTTP GET,POST 호출하는 방법

올리버 — Thu, 3 Feb 2022 17:36:56 +0900

curl 명령어란?

스크립트 또는 쉘상에서 데이터를 전송하기위해 사용되는 command line tool이다.

curl은 다양한 프로토콜을 지원한다.

(HTTP, HTTPS, IMAP, FTP, FTPS, POP3, MQTT, SMTP 등등)

curl 사용을 위한 설치 방법

sudo apt-get install curl

HTTP 호출 방법

URL호출은 다음과 같다.

curl http://test-api.com

HTTP 호출 시 자주 사용하는 옵션은 3가지이다.

-d, --data : Post Request시 보낼 데이터를 설정한다.

-H, --header : Request시 헤더를 설정한다.

-X, --request : 사용할 Request Method 설정한다. EX) GET, POST

-d 옵션을 추가하면 자동적으로 POST로 보내지기 때문에, -X POST 제외 가능

GET 방식

curl -X GET -H "Content-Type: application/json" http://test-api.com?key1=value1&key2=value=2

POST방식

#body에 데이터 포함하여 보내는 방식
curl -X POST \
     -H "Content-Type: application/json" \
     -d "key1=value1&key2=value2" \
     http://test-api.com

#Json 타입으로 데이터 보내는 방식
curl -X POST \
     -H "Content-Type: application/json" \
     -d '{"key1":"value1","key2":"value2"}' \
     http://test-api.com

참고

https://curl.se/

curl

command line tool and library for transferring data with URLs (since 1998) Time to donate to the curl project? Everything curl is a detailed and totally free book that explains basically everything there is to know about curl, libcurl and the associated pr

curl.se