개발 공부

Camel에서 제공하는 Netty Http 컴포넌트 클래스는 org.apache.camel.component.netty.http.NettyHttpComponent이다.

해당 컴포넌트를 이용하여 서버 모드를 기동할 때 org.apache.camel.component.netty.http.NettyHttpEndpoint의 createConsumer()가 호출된다.

    @Override
    public Consumer createConsumer(Processor processor) throws Exception {
        NettyHttpConsumer answer = new NettyHttpConsumer(this, processor, getConfiguration());
        configureConsumer(answer);

        if (nettySharedHttpServer != null) {
            answer.setNettyServerBootstrapFactory(nettySharedHttpServer.getServerBootstrapFactory());
            LOG.info("NettyHttpConsumer: {} is using NettySharedHttpServer on port: {}", answer,
                    nettySharedHttpServer.getPort());
        } else {
            // reuse pipeline factory for the same address
            HttpServerBootstrapFactory factory = getComponent().getOrCreateHttpNettyServerBootstrapFactory(answer);
            // force using our server bootstrap factory
            answer.setNettyServerBootstrapFactory(factory);
            LOG.debug("Created NettyHttpConsumer: {} using HttpServerBootstrapFactory: {}", answer, factory);
        }
        return answer;
    }

getComponent().getOrCreateHttpNettyServerBootstrapFactory(answer)를 호출하게 되는데, getComponent()가 NettyHttpComponent 이고 해당 코드는 아래와 같다.

    protected synchronized HttpServerBootstrapFactory getOrCreateHttpNettyServerBootstrapFactory(NettyHttpConsumer consumer) {
        String key = consumer.getConfiguration().getAddress();
        HttpServerBootstrapFactory answer = bootstrapFactories.get(key);
        if (answer == null) {
            HttpServerConsumerChannelFactory channelFactory = getMultiplexChannelHandler(consumer.getConfiguration().getPort());
            answer = new HttpServerBootstrapFactory(channelFactory);
            answer.init(getCamelContext(), consumer.getConfiguration(), new HttpServerInitializerFactory(consumer));
            bootstrapFactories.put(key, answer);
        }
        return answer;
    }

Address를 key로하여 Map 타입의 bootstrapFactories에 존재여부를 판단하여, 존재하지 않을 경우, 새로운 HttpServerBootstrapFactory 객체를 생성하고, 있을 경우, 그 설정을 그대로 사용.

따라서 초기에 설정하는 HttpServerBootstrapFactory의 NettyServerBootstrapConfiguration이 항상 로드된 채로 사용하게 됨. 

만약 로드된 상태에서, 새롭게 엔드포인트를 활성화할 경우, 기존 캐시에 저장되어 있던 HttpServerBootstrapFactory의 NettyServerBootstrapConfiguration과  새롭게 엔드포인트를 전달한 설정값을 확인하여, 다른 경우 에러 발생함. 코드는 아래와 같음

HttpServerBootstrapFactory.addConsumer

    @Override
    public void addConsumer(NettyConsumer consumer) {
        if (compatibleCheck) {
            // when adding additional consumers on the same port (eg to reuse port for multiple routes etc) then the Netty server bootstrap
            // configuration must match, as its the 1st consumer that calls the init method, which configuration is used for the Netty server bootstrap
            // we do this to avoid mis configuration, so people configure SSL and plain configuration on the same port etc.

            // first it may be the same instance, so only check for compatibility of different instance
            if (bootstrapConfiguration != consumer.getConfiguration()
                    && !bootstrapConfiguration.compatible(consumer.getConfiguration())) {
                throw new IllegalArgumentException(
                        "Bootstrap configuration must be identical when adding additional consumer: " + consumer.getEndpoint()
                                                   + " on same port: " + port
                                                   + ".\n  Existing " + bootstrapConfiguration.toStringBootstrapConfiguration()
                                                   + "\n       New "
                                                   + consumer.getConfiguration().toStringBootstrapConfiguration());
            }
        }

        if (LOG.isDebugEnabled()) {
            NettyHttpConsumer httpConsumer = (NettyHttpConsumer) consumer;
            LOG.debug("BootstrapFactory on port {} is adding consumer with context-path {}", port,
                    httpConsumer.getConfiguration().getPath());
        }

        channelFactory.addConsumer((NettyHttpConsumer) consumer);
    }

만약 새롭게 엔드포인트를 올릴때마다, 옵션이 바뀌는 경우 NettyHttpComponent를 stop하고, 새로운 NettyHttpComponent 객체를 만들던지, bootstrapFactories이 캐싱하는 로직을 제거.

필자는 bootstrapFactories에 캐싱하는 로직을 제거하였음. 다만, 제거하여 현재 어떠한 문제가 발생할지 의문.

서론: 재료를 선택하는 요리사의 지혜

요리를 할 때 재료를 선택하는 것이 중요하듯, 프로그래밍에서도 자료 구조를 선택하는 것은 매우 중요합니다. 오늘 우리는 두 가지 주요 재료, 즉 '배열'과 '리스트'를 비교하며, 왜 리스트를 사용하는 것이 종종 더 나은 선택인지에 대해 탐색해볼 것입니다. 마치 요리사가 재료의 특성을 이해하고 최적의 요리를 만들어내듯, 우리도 각 자료 구조의 특성을 이해하여 더 나은 프로그램을 만들 수 있습니다.

본론: 배열과 리스트, 선택의 기준은?

1. 타입 안전성과 유연성

• 배열은 공변(covariant)입니다. 예를 들어, String[]은 Object[]의 하위 타입입니다. 이러한 특성 때문에 배열을 사용할 때는 타입 불일치로 인한 런타임 오류의 위험이 있습니다.
• 리스트는 불공변(invariant)입니다. List<String>은 List<Object>의 하위 타입이 아닙니다. 이는 컴파일 시점에서 타입 안전성을 제공하며, 잠재적인 오류를 사전에 방지할 수 있게 해줍니다.

2. 크기의 유연성

• 배열은 크기가 고정되어 있습니다. 한 번 생성되면, 그 크기를 변경할 수 없습니다. 이는 데이터의 양이 변동될 때 불편함을 초래할 수 있습니다.
• 리스트는 크기가 동적입니다. 데이터를 추가하거나 제거하면서 크기가 자동으로 조정됩니다. 이는 데이터 관리를 훨씬 더 유연하게 만들어 줍니다.

3. 기능성과 편의성

• 배열은 기본 기능만 제공합니다. 배열을 사용할 때는 길이를 알아내거나, 특정 인덱스의 요소에 접근하는 기본적인 기능 외에는 추가적인 기능을 직접 구현해야 합니다.
• 리스트는 다양한 유틸리티 메서드를 제공합니다. add, remove, contains와 같은 메서드는 데이터를 다루는 작업을 쉽고 효율적으로 만들어 줍니다. 또한, Collections 클래스는 리스트를 정렬하거나 검색하는 데 필요한 다양한 유틸리티 메서드를 제공합니다.

결론: 요리사가 최적의 재료를 선택하듯

배열과 리스트 각각의 특성을 이해하는 것은 프로그래머에게 매우 중요합니다. 배열은 그 간단함과 성능으로 특정 상황에서 유용할 수 있지만, 타입 안전성, 크기의 유연성, 그리고 편의성 측면에서 리스트가 더 나은 선택일 수 있습니다. 프로그램의 안정성을 높이고, 유지보수를 용이하게 하며, 더 나은 코드 작성을 위해서는 '리스트 사용하기'가 훌륭한 조언이 될 수 있습니다. 마치 요리사가 각 재료의 특성을 이해하고 최적의 재료를 선택하는 것처럼, 우리도 각 상황에 맞는 최적의 자료 구조를 선택하는 지혜가 필요합니다.

서론: 경고 신호에 주목하라

여러분이 차를 운전하고 있다고 상상해보세요. 갑자기 대시보드에 경고등이 켜집니다. 이때 대부분의 사람들은 경고등을 무시하고 계속 운전하지 않을 거예요. 차량의 안전과 성능을 위해 문제를 조사하고 해결할 필요가 있죠. 프로그래밍에서도 마찬가지입니다. 자바나 다른 프로그래밍 언어에서 컴파일러가 경고를 발생시킬 때, 그것은 우리에게 뭔가 문제가 있음을 알리는 신호입니다. "비검사 경고를 제거하라"는 이 경고들에 주목하고 해결해야 한다는 메시지를 전달합니다. 그렇다면 왜 이 경고들이 중요한 걸까요?

본론: 비검사 경고의 의미와 해결법

1. 비검사 경고란 무엇인가?

비검사 경고는 주로 제네릭스를 사용할 때 발생합니다. 컴파일러가 타입 안정성을 보장할 수 없을 때, 예를 들어 제네릭 타입을 명시하지 않고 사용할 때 이런 경고가 발생합니다. 비검사 경고는 런타임에 ClassCastException과 같은 오류로 이어질 수 있는 문제들을 미리 알려줍니다.

2. 경고의 중요성

비검사 경고를 무시하면, 프로그램이 예상치 못한 방식으로 실패할 가능성이 있습니다. 이는 개발 과정에서 쉽게 발견되지 않는 버그를 의미할 수 있으며, 이런 버그는 나중에 찾아내고 수정하기 훨씬 어려울 수 있습니다.

3. 경고 제거하기

• 경고를 해결하는 가장 좋은 방법은 제네릭을 올바르게 사용하는 것입니다. 예를 들어, List 대신 List<String>을 사용해 명시적으로 타입을 선언해줌으로써 타입 안전성을 보장할 수 있습니다.
• 경고를 피할 수 없는 경우, 그리고 그것이 안전하다고 확신하는 경우에는 @SuppressWarnings("unchecked") 어노테이션을 사용해 경고를 숨길 수 있습니다. 하지만 이 어노테이션은 가능한 최소한으로, 그리고 그 사용 사유를 주석으로 남기면서 신중하게 사용해야 합니다.

결론: 안전한 코드를 위한 지속적인 노력

비검사 경고를 제거하는 것은 코드의 안정성과 유지보수성을 높이는 중요한 단계입니다. 컴파일러의 경고를 무시하는 것은 잠재적인 문제를 무시하는 것과 같습니다. 따라서, 이러한 경고에 주목하고 해결하여 보다 안전하고 신뢰할 수 있는 코드를 작성해야 합니다. 마치 운전 중 대시보드의 경고등에 주목하고 필요한 조치를 취하는 것처럼, 프로그래밍에서도 비검사 경고에 주목하고 적절히 대응해야 합니다. 이렇게 함으로써, 우리는 더 나은 소프트웨어 개발자가 될 수 있습니다.

서론: 위험한 숲 속의 금지된 과일

상상해 보세요. 마법의 숲에 금지된 과일이 있는데, 이 과일을 먹으면 순간적으로 힘이 솟구치지만, 이내 큰 대가를 치르게 된다는 전설이 있습니다. 프로그래밍의 세계에서도 비슷한 금지된 과일이 있어요. 바로 '로 타입(raw types)'입니다. 이번 모험에서는 왜 로 타입을 사용하지 않아야 하는지, 그리고 그 대안은 무엇인지 함께 탐험해 보겠습니다.

본론: 로 타입의 유혹과 그 위험성

1. 로 타입이란 무엇인가?

자바에서 제네릭스(Generics)가 도입되기 전, 모든 컬렉션은 로 타입이었습니다. 예를 들어, List는 어떤 타입의 객체든지 저장할 수 있었죠. 제네릭스의 도입으로 List<String> 또는 List<Integer>와 같이 저장될 객체의 타입을 지정할 수 있게 되었습니다. 하지만 여전히 로 타입을 사용할 수는 있습니다. 문제는 여기서 시작됩니다.

2. 로 타입의 위험성

• 타입 안정성 부족: 로 타입을 사용하면 컴파일 타임에 타입 체크를 할 수 없어, 런타임에 ClassCastException과 같은 예외가 발생할 위험이 커집니다.
• 코드 읽기 어려움: 제네릭스를 사용하면 코드를 읽고 이해하기가 더 쉬워집니다. 로 타입을 사용하면 어떤 타입의 객체가 저장되는지 바로 알 수 없어 코드의 가독성이 떨어집니다.
• API 사용의 제한: 제네릭 타입으로 작성된 메서드는 로 타입으로는 제대로 사용할 수 없습니다. 이는 API 사용에 제한을 초래할 수 있습니다.

3. 안전한 대안, 제네릭스 사용하기

• 타입 안정성 보장: 제네릭을 사용하면 컴파일 타임에 타입 체크를 할 수 있어, 런타임에 발생할 수 있는 오류를 대폭 줄일 수 있습니다.
• 코드 가독성 향상: 제네릭스를 사용하면 저장되는 객체의 타입을 명확히 할 수 있어, 코드를 더 쉽게 이해할 수 있습니다.
• 유연성: 제네릭 메서드와 클래스를 사용하면, 다양한 타입에 대해 유연하게 코드를 작성할 수 있습니다.

결론: 금지된 과일을 피하고, 안전한 길을 선택하자

로 타입을 사용하는 것은 마치 숲속의 금지된 과일을 먹는 것과 같습니다. 잠시 편리할 수 있지만, 결국엔 큰 대가를 치를 수 있어요. 반면, 제네릭스를 사용하는 것은 안전하고 명확한 길을 선택하는 것입니다. 코드의 안정성을 보장하고, 가독성을 높이며, 유연한 프로그래밍이 가능해집니다. 프로그래밍의 숲에서 금지된 과일인 로 타입을 멀리하고, 제네릭스라는 안전한 길을 선택해보세요. 여러분의 코드 여행이 더욱 즐겁고 안전해질 거예요.

디자인 패턴 중 일반적으로 가장 처음에 배우는 전략 패턴을 자바로 어떻게 작성해야 하는지에 대한 내용이다.

전략 패턴에 대한 설명은 생략한다.

문자열 비교를 해주는 Util이 있다고 가정해보자.

public class StringCompareUtil {

	/**
	 * 일반 문자열 비교
	 */
	public static int compare(String s1, String s2) {
		return s1.compareTo(s2);
	}

	/**
	 * 문자열 길이를 이용한 비교
	 */
	public static int compareLength(String s1, String s2) {
		return s1.length() - s2.length();
	}

}

만약 새로운 문자열 비교 기능이 필요하다면 위 클래스를 수정해야 한다.  OCP를 위반하기 때문에 인터페이스를 이용하여 클래스를 변경해보자.

public interface Comparator {
	public int compare(String s1, String s2);

}

public class NormalStringCompare implements Comparator {

	public int compare(String s1, String s2) {
		return s1.compareTo(s2);
	}

}

public class LengthStringCompare implements Comparator {

	public int compare(String s1, String s2) {
		return s1.length() - s2.length();
	}

}

인터페이스를 이용하였고 각 기능을 제공하는 클래스를 각각 구현하였다. 이런 식으로 작성한다면 해당 기능을 사용하는 클라이언트 입장에서는 어떠한 구현체여도 인터페이스를 사용하기만 하면 된다.

문자열만 비교하는 인터페이스로 사용하기에 아쉽기 때문에 제네릭을 추가하자.

public interface Comparator<T> {
	public int compare(T s1, T s2);

}


public class NormalStringCompare implements Comparator<String> {

	public int compare(String s1, String s2) {
		return s1.compareTo(s2);
	}

}

public class LengthStringCompare implements Comparator<String> {

	public int compare(String s1, String s2) {
		return s1.length() - s2.length();
	}

}

새로운 비교 기능을 위해 클래스를 새롭게 구현해도 되지만, 기능이 추가될 때마다 클래스의 개수가 계속 늘어나게 된다. 만약 해당 비교 기능을 특정한 클라이언트 구현체에서만 사용한다면 익명 클래스를 이용해서 해당 위치에서 작성해주자.

		new Comparator<String>() {
			public int compare(String s1, String s2) {
				// TODO
			}
		};

위와 같이 익명 클래스를 생성하면 해당 위치에서 새로운 객체가 계속 만들어지므로 해당 익명 클래스를 객체로 갖는 private static final 필드에 저장하고 재사용하는 것을 고려하자.

여기까지 책에 대한 설명이다. 참고로 블로그 저자는 2판을 보고 작성하고 있는데, 3판에서는 람다에 대한 챕터로 해당 내용을 새롭게 구성하여 설명하고 있다.

이제 익명 클래스 대신에 람다를 사용하는 것을 추천한다. 람다에 대한 설명은 다른 블로그 글을 참조하기 바란다.

이 챕터는 자바를 처음 배울 때 계층형(추상) 클래스를 사용하는 이유를 설명하는 내용이라고 생각해도 될 것 같다. 그만큼 내용이 어렵지 않으므로 간단하게 설명한다.

1. 태그 클래스란?

태그 클래스란 특정한 변수를 기준으로 분기하여 두 가지 이상의 기능을 제공하는 클래스를 의미한다.

public class Figure {
	enum Shape {
		RECTANGLE, CIRCLE
	};

	final Shape shape;

	double length;
	double width;

	double redius;

	Figure(double length, double width) {
		this.shape = Shape.RECTANGLE;
		this.length = length;
		this.width = width;
	}

	Figure(double redius) {
		this.shape = Shape.CIRCLE;
		this.redius = redius;
	}

	double area() {
		switch (shape) {
		case RECTANGLE:
			return length * width;
		case CIRCLE:
			return Math.PI * (redius * redius);
		default:
			throw new AssertionError();
		}
	}
}

A 기능을 위한 생성자와 인스턴스 필드들이 존재하며, B 기능을 위한 생성자와 인스턴스 필드들이 각각 존재한다.

이러한 경우 단점은 다음과 같다.

1. 가독성이 떨어진다.

2. 필요 없는 기능을 위한 필드도 함께 생성되므로 메모리 요구량이 늘어난다.

3. 또 다른 기능이 생긴다면 해당 클래스를 수정해야 하며, swtich문도 모두 수정해야 한다.

2. 해결 방안

공통 기능은 추상(abstract) 클래스로 옮기고 서로 다른 기능은 하위 클래스로 구현한다.

이전에 작성한 글로 대신한다.

[JAVA] Constant Interface : 상수를 정의한 인터페이스

이 챕터에서는 우리가 자주 사용하는 extends(상속을 통한 확장) 보다 해당 클래스를 참조하는 private 필드를 선언해서 사용하는 것이 더 좋은 이유에 대해 설명한다.

(이 챕터 내용과 비슷하게 스프링 바이블인 '토비의 스프링' 책에서도 관심사의 분리, 제어의 역전, 콜백 패턴 등을 설명할 때 계승보다는 구성을 사용하는 것이 좋다고 설명한다.)

계승의 문제점

계승은 상위 클래스와 하위 클래스가 밀접한 관계를 가진다. 하위 클래스는 상위 클래스의 구현에 의존할 수밖에 없기 때문에 캡슐화 원칙을 위반한다. 즉 상위 클래스의 구현이 변경되면 하위 클래스는 기존에 구현한 코드가 원하는 방식으로 동작하지 않을 수 있다.

계승을 하기 위해서는 상위 클래스 구현에 대해 잘 알아야 한다. 그렇지 않을 경우 하위 클래스가 원하는 방식으로 동작하지 않을 수 있는데 예를 들어보자.

java.util에서 제공하는 HashSet 클래스를 상속하여 원소가 추가될 때마다 카운팅을 하는 클래스를 아래와 같이 구현했다.

public class CountHashSet<E> extends HashSet<E> {
	private int addCount = 0;

	public CountHashSet() {

	}

	public CountHashSet(int initCap, float loadFactor) {
		super(initCap, loadFactor);
	}

	@Override
	public boolean add(E e) {
		addCount++;
		return super.add(e);
	}

	@Override
	public boolean addAll(Collection<? extends E> c) {
		addCount += c.size();
		return super.addAll(c);
	}
}

심플한 클래스로 잘 동작할 것 같지만 addAll()을 호출할 경우 문제가 발생한다. addAll()에서 super.addAll()은 java.util.AbstractCollection 클래스의 addAll()을 호출하는데 구현 코드는 아래와 같다.

    public boolean addAll(Collection<? extends E> c) {
        boolean modified = false;
        for (E e : c)
            if (add(e))
                modified = true;
        return modified;
    }

코드를 보면 알겠지만 addAll()에서 다시 add()를 호출한다. 따라서 위에서 구현한 코드는 중복 계산되므로 addAll()을 호출하게 되면 항상 원소의 두 배만큼 증가한다.

해당 버그를 fix 하기 위해 addAll() 재정의 메서드를 제거하더라도 나중에 addAll()에서 add()를 호출하지 않으면 문제가 다시 발생한다. 다른 방법으로 super.addAll()을 호출하지 않고 직접 구현하면 된다. 하지만 상위 클래스의 동작을 위해 직접 구현하기 어려울 뿐 아니라, 접근 불가능한 필드가 있을 경우 구현은 아예 불가능하다.

이외에도, 상위 클래스에 또 다른 원소를 추가하는 메서드가 생겨나게 된다면 하위 클래스에서는 매번 릴리즈 노트를 확인해야 할 것이다.

하위 클래스가 상위 클래스를 망가뜨릴 수 있다. 만약 HashSet에 특정 조건을 만족해야지만 add 할 수 있는 메서드가 있다면 하위 클래스도 add를 재정의할 때 해당 조건을 추가해서 구현해야지 상위 클래스를 만족한다. 하지만 잘못된 사용자는 하위 클래스를 이용하여 해당 조건을 넣지 않아 상위 클래스를 망가뜨릴 수 있다.

계승보다 구성

위와 같은 계승의 문제점은 구성(필드 선언)을 통해 해결할 수 있다. 소스는 아래와 같다.

public class CountHashSetByComposit<E> {
	private int addCount = 0;
	private Set<E> s;

	public CountHashSetByComposit(Set<E> s) {
		this.s = s;
	}

	public boolean add(E e) {
		addCount++;
		return s.add(e);
	}

	public boolean addAll(Collection<? extends E> c) {
		addCount += c.size();
		return s.addAll(c);
	}
}

(책에서는 Set 인터페이스를 구현하는 전달 클래스를 하나 만들어 Wrapper 클래스로 예를 들었다.)

위 클래스는 어떤 Set 객체를 인자로 받아 필요한 부분만 사용하고, 추가적인 기능은 직접 구현하였다. 계승 대신 구성을 하게 되면 사용하고자 하는 메서드에 대해서만 이해하면 되고, 해당 클래스의 API의 일부가 변경되어도 구성을 사용한 클래스를 알 필요 없다.

계승은 상위 클래스와 하위 클래스 사이에 IS-A 관계가 확실할 때만 사용하는 것이 좋다. IS-A 관계가 확실하다고 해도 내가 구현한 상위 클래스가 아니라면 계승보다는 구성이 낫다. 즉 계승은 상위 클래스와 하위 클래스 구현을 같은 개발자가 구현한다면 고려해도 된다. 하지만 구성을 하게 되면 하위 클래스보다 견고할 뿐 아니라, 더 강력하다.