[모던자바인액션] 동작 파라미터화 : 동작 자체를 전달해보자!

💬 모던 자바 인 액션 챕터 2을 읽고 정리한 글입니다. 

 

---

✔️ 동작 파라미터화

사람의 마음은 정말 갈대 같다. 그리고, 요구사항은 소비자의 입장에서 늘 생각하게 된다. 우리는 코드를 짜는 프로그래머지만, 갈대 같은 소비자의 마음을 만족시키기 위해 최대한 유동적으로 대응할 필요가 있다.

어느 날, 포비가 우테코 공지사항에 다음과 같은 요구사항을 던져주었다고 가정하자.

 

💬 백엔드 크루 중에 25살 이하인 크루만 보고 싶은데, 모여 주세요.

 

그러자 네오가 와서 말했다.

💬 아니에요, 프론트엔드 크루 중에서 23살 이상인 크루만 와주세요.

 

어떻게 하면 우리는 변화하는 요구사항 속에서 유동적으로 대응할 수 있을까?

가장 먼저, 그냥 요구사항에 맞도록 가능한 모든 속성에 대해서 전부 시도하는 방법이 있다.

 

1) 백엔드 크루면서 25살 이하인 크루 모으기

2) 프론트엔드 크루면서 23살 이하인 크루 모으기

3) 안드로이드 크루면서... (etc)

뿌듯한 마음으로 모든 조건에 대해서 대응을 했다. 하지만, 이때 지나가던 리사가 와서 말을 건넨다.

 

💬 어, 내일은 백엔드 크루 중에서 이름에 'ㅈ'이 들어가는 크루들만 모여 주세요!

 

결국, 내일도 비슷한 로직을 100개 쓰면서 칼퇴를 못하는 상황이 발생하게 될 것이다 🤯

 

💡 비슷한 코드가 반복해서 존재한다면, 해당 코드를 추상화하자.

현재의 요구사항을 생각해보자. 우선, 우리의 대장 포비의 요구사항을 만족하기 위해 다음과 같은 조건을 생각할 수 있다.

1) 백엔드 크루라면 통과, 아니라면 땡!
2) 25살 이하인 크루라면 통과, 아니라면 땡!

 

우리는 위 문장을 보고 무언가 중복되는 걸 찾을 수 있다. '~라면 통과, ~가 아니라면 땡!' 즉, 두 조건 모두 참과 거짓에 대해서 반환을 하고 있다는 것을 알 수 있다. 참과 거짓이라고 하면 무언가가 생각난다. 바로, boolean 값이다. 그리고, 자바에서는 참/거짓에 대응하기 위해, 꽤나 멋진 함수형 인터페이스를 제공하고 있다. 

@FunctionalInterface
public interface Predicate<T> {
        boolean test(T t);
        }

물론, 이 친구에 대해 지금은 몰라도 된다. 우리는 이 친구를 모방해서 'CrewPredicate'라는 함수형 인터페이스를 만들 것이다. 우리는 현재 '크루'에 대해서 '무슨무슨 조건으로 필터링!'을 하고 싶은 것이기 때문에, 크루를 인자로 받아서 필터링 조건은 내부 구현체에게 맡기는 방향으로 설계를 진행할 것이다. 그럼, 다음과 같은 인터페이스를 생성할 수 있다.

 

public interface CrewPredicate {
    boolean test (Crew crew);
}

이 친구는 이제, 인자로 들어온 Crew에 대해서 판단하고, 구현 클래스를 통해서 선택 조건에 대해 구체화를 진행할 것이다. 우리의 현재 조건인 '백엔드 크루'와 '25살 이하인 크루'를 뽑기 위해 다음과 같은 구현 클래스를 생성할 수 있다.

 

// 백엔드 크루를 뽑는 클래스.
public class BackendCrewPredicate implements CrewPredicate {
    public boolean test(Crew crew) {
        return crew.getCourse.equals(BACKEND);
    }
}

// 25살 이하인 크루를 뽑는 클래스.
public class AgeCrewPredicate implements CrewPredicate {
    public boolean test(Crew crew) {
        return crew.getAge() <= 25;
    }
}

위 상황에 맞춰서 다양한 동작을 실행하고 있다. "상황에 따라 다른 동작을 실행해?" -> 맞다, 전략 패턴이다. 인터페이스를 통해서 우리는 '조건은 모르겠고, 그냥 맞는지 아닌지에 대한 정보를 줄 거야!'라는 것만 선언해두고, 내부적인 로직은 구현체에게 위임하여 상황에 따라 백엔드 크루도 뽑고, 25살 이하인 크루도 뽑을 수 있도록 '갈아끼우는' 로직을 만들어낸 것이다.

 

우리는 이것을 조금 더 멋진 말로 표현할 수 있다.

💡 각각의 알고리즘을 '캡슐화'하는 알고리즘 패밀리를 정의하고, 런타임에 알고리즘을 선택하게 만들자.

여기서 우리는 인터페이스를 통해 캡슐화를 진행했으며, CrewPredicate가 일종의 알고리즘 패밀리다. 그리고 BackendCrewPredicate / AgeCrewPredicate가 일종의 전략이 된다.

 

우리는 이제, 이러한 전략을 동적으로 받아서 실행할 수 있도록 코드를 작성할 수 있다.

// 인자로 들어온 predicate의 구체 클래스에 대해서 필터 조건을 변경할 수 있다.
public List<Crew> filterCrews(List<Crew> crews, CrewPredicate p) {
        List<Crew> resultCrews = new ArrayList<>();
        for (Crew crew : crews) {
        if (p.test(crew) {
        resultCrews.add(crew);
        }
        }
        }

우리는 이제, '백엔드 크루를 뽑는 것', '25살 이하인 크루를 뽑는 것' 같은 어떠한 '동작' 자체를 파라미터로 전달해줄 수 있게 되었다. 이때, 파라미터로 인터페이스를 사용하여 해당 인터페이스의 구현체가 자유롭게 들어와서 전략을 선택할 수 있도록 만든 것이다.

 

하지만, 위 코드도 무언가 불편하다. 우리는 지금 포비의 요구사항만 만족하는 구현 클래스를 만들었을 뿐이다. 네오의 요구사항인 '프론트엔드 크루'나 '23살 이상의 크루', '이름에 ㅈ이 들어가는 크루' 등, 요구사항이 많아진다면 해당 요구사항 각각에 맞는 구현 클래스를 또 만들어줘야 한다는 것이다. 귀찮음이 많은 개발자는 이를 참을 수 없다.

 

---

 

 ✔️ 리팩터링 진행하기 - 익명 클래스!

어떻게 하면 이를 개선할 수 있을까? 구현 클래스를 만들지 않고 문제를 해결하는 방법은 없을까? 바로, 클래스의 선언과 인스턴스화를 동시에 진행할 수 있는 '익명 클래스'를 활용하는 것이다. 익명 클래스는 이름이 없는 클래스이다. 클래스명에 대한 네이밍에 대해 고민할 필요도 없으며, 네이밍이 없기 때문에 외부에서 호출할 수 없어 딱 1번만 사용하게 된다. 

// 리팩터링 이전의 코드, 기존에는 이런 식으로 클래스를 선언해주었다.
List<Crew> backendCrews = filterCrews(crews, new BackendCrewPredicate());
        List<Crew> ageCrews = filterCrews(crews, new AgeCrewPredicate());

// 익명 클래스를 활용해보자!
// CrewPredicate를 구현하는 객체를 만드는 것이다.
        List<Crew> backendCrews = filterCrews(crews, new CrewPredicate() {
@Override
public boolean test(Crew crew) {
        return crew.getCourse.equals(BACKEND);
        }
        });

        List<Crew> ageCrews = filterCrews(crews, new CrewPredicate() {
@Override
public boolean test(Crew crew) {
        return crew.getAge() <= 25;
        }
        });

위 코드를 보면, CrewPredicate 인터페이스의 구현체를 바로 인자 내에서 구현한 것을 볼 수 있다. 그러나, 위 코드 역시 여전히 불편하다. 우리가 필요한 건 내부의 필터링 조건이지만, public boolean test() {...} 같이 메서드 선언을 위한 코드가 계속해서 따라 붙는다는 것이다. 코드가 길어지면 개발자는 읽고 싶지가 않아진다. 또한, 앞서 말한 것처럼 재사용도 되지 않는다는 것이다.

 

---

 ✔️ 리팩터링 진행하기 - 람다

어떻게 하면 더 짧게 줄일 수 있을까? 우리는, 다른 건 다 필요없고 오직 조건에 대한 '동작'만 필요하다. test 메서드에 대한 건 별로 알고 싶지 않고, 그냥 'crew.getAge() <= 25'라는 필터링 행위만 필요한 것이다. 우리는 이를 해결하기 위해 '람다 표현식'이라는 것을 사용할 수 있다.

// 람다 사용하기
List<Crew> backendCrews = filterCrews(crews, (Crew crew) ->
        crew.getCourse.equals(BACKEND)
        );

        List<Crew> ageCrews = filterCrews(crews, (Crew crew) ->
        crew.getAge() <= 25
        );

놀랍게도, 불필요한 코드가 제거되고 나니 크루에 대한 조건이 더 명확하게 보이는 것을 볼 수 있다. 우리는 현재 '동작' 에 대해서 파라미터로 넘겨준 것이다! 우리는 이러한 '동작 파라미터화'를 통해 유연성을 높이고, 람다를 통해서 코드를 간결하게 작성할 수 있는 멋진 개발자가 된 것이다.

 

---

✔️ 제네릭 활용하기

우리는 이제 동작에 대한 고민은 끝났다. 하지만, 만약 크루가 아닌 코치에 대한 정보를 필터링하고 싶다면 어떻게 하면 좋을까? 동작의 대상에 대해서도 외부에서 주입받아서 처리하도록 만들면 어떨까?🤔 기존에 만든 CrewPredicate는 크루에 대한 조건 판단을 해주는 함수형 인터페이스였기 때문에, 자바에서 제공해주는 Predicate<T>를 이용해보자. 또한, 제네릭을 활용하여 크루든, 코치든 대상에 신경쓰지 않고 조건 필터링을 할 수 있도록 해보자!

public interface Predicate<T> {
        boolean test(T t);
        }

public static <T> List<T> filter(List<T> list, Predicate<T> p) {
        List<T> result = new ArrayList<>();
        for(T e: list) {
        if(p.test(e)) {
        result.add(e);
        }
        }
        return result;
        }

이렇게 제네릭을 활용하여 추상화를 하게 되면 크루뿐만 아니라 코치, 그리고 다른 것들에 대해서도 필터 메서드를 사용할 수 있게 되었다. 우리는 이제 확장성까지 갖추게 된 것이다 👏

 

 

💡 메서드 참조 vs 람다식

흔히 메서드 참조와 람다식을 많이 비교하여 사용한다. 지난 챕터1에서는 메서드 참조를 다루었는데, 우리는 람다식에서 메서드 참조를 활용하면 더 짧고 간결하게 코드를 작성할 수 있다. 예를 들어, 위 코드에서 람다식을 활용하여 호출하면 다음과 같이 사용할 수 있다.

public static void main(String[] args) {
        List<Crew> crews = new ArrayList<>();
        filter(crews, (Crew crew) -> crew.getAge() <= 25);
        }

        ...

하지만, 만약 나이에 대한 조건을 재사용하고 싶다면, 그리고 '메서드명을 통해서 명확하게 해당 조건을 나타내고 싶다면' 메서드 참조를 사용하는 것도 하나의 방법이다. (혹은, 람다 내부의 구현식이 너무 길어도 메서드 참조를 사용하는 게 하나의 방법이 된다.) 메서드 참조를 사용하면 다음과 같이 작성할 수 있다. 메서드 참조에 대한 설명은 챕터 3에서 조금 더 자세히 설명할 예정이다 🤭

public void main(String[] args) {
        List<Crew> crews = new ArrayList<>();
        filter(crews, this::isCrewAgeUnder);
        }

private boolean isCrewAgeUnder(final Crew crew) {
        return crew.getAge() <= 25;
        }

        ...

위와 같이 메서드 참조를 활용하여 여러 번 재사용할 수는 있다. (메서드 참조에 예제를 맞추려고 하다 보니 좀 이상해진 감이 있지만... 저런 느낌으로 사용할 수 있다.) 아니면, 조금 더 객체지향으로 사용하기 위해서는 이 방법이 더 나을 것 같다.

public class Crew {
    private final String name;
    private final String nickname;
    private final int age;
    private final Course course;

	...

    public boolean isCrewAgeUnder(final int age) {
        return this.age <= age;
    }
}

 public void main(String[] args) {
        List<Crew> crews = new ArrayList<>();
        filter(crews, crew -> crew.isCrewAgeUnder(25));
        }

        ...

코드에 정답은 없기 때문에, 그때그때 상황에 따라서 쓰면 좋을 것 같다!

 

---

✔️ Comparator로 정렬하기

그 외에도, 다양한 활용 예제들이 있다. 대표적으로 Comparator와 Runnable에 대해서 간략하게만 살펴보자. 자바 8에서 List에는 sort 메서드가 포함되어 있다. (인터페이스에 디폴트 메서드인 sort가 구현되어 있는 형태이다) 이때, Comparator 인터페이스를 활용하면 sort의 동작을 다양화할 수 있게 된다.

// 1단계 - Comparator의 구현체 생성하기
crews.sort(new Comparator<Crew>() {
@Override
public int compare(Crew o1, Crew o2) {
        return Integer.compare(o1.getAge(), o2.getAge());
        }
        });

// 2단계 - 람다를 활용하여 간결하게 만들기
        crews.sort((o1, o2) -> Integer.compare(o1.getAge(), o2.getAge()));

// 3단계 - 이후 챕터에서 나올 내용. 일단은 더 간결하게 줄일 수 있다는 것 정도만 알아두자.
        crews.sort(Comparator.comparingInt(Crew::getAge));

 

✔️ Runnable로 코드 블록 실행하기

자바의 스레드를 활용하면, 병렬로 코드 블록을 실행할 수 있다. 이때, Runnable 인터페이스를 활용하여 실행할 코드 블록을 지정할 수 있다. Runnable 역시, run()이라는 추상 메서드를 가지고 있는 함수형 인터페이스이다.

@FunctionalInterface
public interface Runnable {
    public abstract void run();
}

그리고, 이러한 Runnable을 활용하여 다양한 동작을 스레드로 실행할 수 있다. 특히, 자바 8에서는 람다 표현식을 활용하여 다음과 같이 더 간단하게 표현하여 스레드에게 동작을 건네줄 수 있게 된다.

Thread t = new Thread(() -> System.out.println("Hello world"));

 

---

💬 정리

1) 동작 파라미터화를 통해 내부적으로 다양한 동작을 진행할 수 있도록, 코드를 메서드의 인수로 전달한다. 이렇게 하면 요구사항에 더 유연하게 대응할 수 있다.

2) 익명 클래스 및 람다를 활용하여 코드를 더 간결하게 유지할 수 있다.

 

 

 

챕터 2에서는 동작 파라미터화에 대해서 더 자세히 알아보았다.

챕터 3에서는 람다 표현식에 대해서 알아보도록 하자 💪 아마 내용이 길어서 두 개로 나눠서 쓸 것 같다.