내부 반복자를 사용하므로 병철 처리가 쉽다

외부 반복자란 개발자가 코드로 직접 컬렉션의 요소를 반복해서 가져오는 코드 패턴을 말합니다. index를 이용하는 for문 그리고 Iterator를 이용하는 while문은 모두 외부 반복자를 이용하는 것입니다. 반면에 내부 반복자는 컬렉션 내부에서 요소들을 반복시키고, 개발자는 요소당 처리해야 할 코드만 제공하는 코드 패턴을 말합니다. 아래 그림을 보면 알수 있습니다.

외부 반복자와 내부반복자 그림

스크린샷 2019-12-03 오후 7 54 31

내부 반복자를 사용해서 얻는 이점은 컬렉션 내부에서 어떻게 요소를 반복시킬 것인가는 컬렉션에 맡겨두고, 개발자는 요소 처리 코드에만 집중할 수 있다는 것입니다. 내부 반복자는 요소들의 반복 순서를 변경하거나, 멀티 코어 CPU를 최대한 활용하기 위해 요소들을 분배시켜 병렬 작업을 할 수 있게 도와주기 때문에 하나씩 처리하는 순차적 외부 반복자보다는 효율적으로 요소를 반복시킬 수 있습니다.

병렬 처리란?

병렬 처리란 한 가지 작업을 서브 작업으로 나누고, 서브 작업들을 분리된 스레드에서 병렬적으로 처리하는 것을 말합니다. 병렬 처리 스트림을 이용하면 런타임 시 하나의 작업을 서브 작업으로 자동으로 나누고, 서브 작업의 결과를 자동으로 결합해서 최종 결과물을 생성합니다. 예를들어 컬렉션 요소 총합을 구할 때 순차 처리 스트림은 하나의 스레드가 요소들을 순차적으로 읽어 합을 구하지만, 병렬 처리 스트림을 이용하면 여러 개의 스레드가 요소들을 부분적으로 합하고 이 부분합을 최종 결합해서 전체 합을 생성합니다.

아래 코드는 순차 처리 스트림과 병렬 처리 스트림을 이용할 경우, 사용된 스레드의 이름이 무엇인지 콘솔에서 출력하는 예제입니다. 실행결과를 보면 병렬 처리 스트림은 main 스레드를 포함해서 ForkJoinPool(스레드 풀)의 작업 스레드들이 병렬적으로 요소를 처리하는 것을 볼 수 있습니다.

//병렬처리
import java.util.Arrays;
import java.util.List;
import java.util.stream.Stream;

public class ParallelExample {

    public static void main(String[] args) {
        List<String> list = Arrays.asList(
                "홍길동", "신용권", "김자바"
                ,"람다식","박병렬"
        );
        // 순차 처리
        Stream<String> stream = list.stream();
        stream.forEach(ParallelExample :: print);
        System.out.println();

        // 병렬 처리
        Stream<String> parallelStream = list.parallelStream();
        parallelStream.forEach(ParallelExample::print);

    }

    private static void print(String str) {
        System.out.println(str + " : " + Thread.currentThread().getName());
    }
}

실행결과

스크린샷 2019-12-03 오후 8 34 16

스트림은 중간 처리와 최종 처리를 할 수 있습니다.

스트림은 컬렉션 요소에 대해 중간 처리와 최종 처리를 수행할 수 있는데, 중간 처리에서는 매핑, 필터링, 정렬을 수행하고 최종 처리에서는 반복, 카운팅, 평균, 총합 등의 집계
처리를 수행합니다.

아래 예제는 List에 저장되어 있는 Student 객체를 중간 처리에서 score 필드 값으로 매핑하고, 최종 처리에서 score 평균값을 산출합니다.

import java.util.Arrays;
import java.util.List;

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

        List<Student> students = Arrays.asList(
                new Student("임준영",100),
                new Student("배성탑",90),
                new Student("임광빈",80),
                new Student("양아름",75)
        );

        double avg = students.stream()
                .mapToInt(Student::getScore) // 중간처리(학생 객체를 점수로 매핑)
                .average()
                .getAsDouble();

        System.out.println("평균 점수: " + avg);
    }
}

스트림의 종류

자바 8부터 새로 추가된 java.util.stream 패키지에는 스트림 API들이 포진하고 있습니다. 패키지 내용을 보면 BaseStream 인터페이스를 부모로 해서 자식 인터페이스들이 아래 이미지처럼 상속 관계를 이루고 있습니다.

스크린샷 2019-12-03 오후 10 00 15

BaseStream 인터페이스에는 모든 스트림에서 사용할 수 있는 공통 메소드들이 정의되어 있을 뿐 코드에서 직접적으로 사용되지는 않습니다. 하위 스트림인 Stream, IntStream,
LongStream, DoubleStream이 직접적으로 이용되는 스트림인데, Stream은 객체 요소를 처리하는 스트림이고, IntStream,LongStream, DoubleStream은 각각 기본 타입인 int, long, double 요소를 처리하는 스트림입니다. 이 스트림 인터페이스의 구현 객체는 다양한 소스로부터 얻을 수 있습니다. 주로 컬렉션과 배열에서 얻지만, 다음과 같은 소스로부터 스트림 구현 객체를 얻을 수도 있습니다.

스크린샷 2019-12-15 오후 11 31 37

컬렉션으로부터 스트림 얻기

다음 예제는 List 컬렉션에서 Stream를 얻어내고 요소를 콘솔에 출력합니다.

import java.util.Arrays;
import java.util.List;

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

        List<Student> students = Arrays.asList(
                new Student("임준영",100),
                new Student("배성탑",90),
                new Student("임광빈",80)
        );

        students.forEach(s -> System.out.println(s.getName()));

    }
}


package stream;

public class Student {

    private String name;
    private int score;

    public Student(String name, int score) {
        this.name = name;
        this.score = score;
    }

    public String getName() {
        return name;
    }

    public int getScore() {
        return score;
    }

}

숫자 범위부터 스트림 얻기

아래 예제 코드는 1부터 100까지의 합을 구하기 위해 IntStream의 rangeClosed() 메소드를 이용하였습니다. rangeClosed()는 첫 번째 매개값에서부터 두 번째 매개값까지 순차적으로 제공하는 IntStream을 리턴한다. IntStream의 또 다른 range() 메소드도 동일한 IntStream을 리턴하는데, 두 번째 매개값은 포함하지 않습니다.

import java.util.stream.IntStream;

public class FromIntRangeExample {

    public static int sum;

    public static void main(String[] args) {

        IntStream intStream = IntStream.rangeClosed(1,100);
        intStream.forEach(a -> sum += a);
        System.out.println("총합 :" +  sum);

    }
}

파일로부터 스트림 얻기

아래 예제 코드는 Files의 정적 메소드인 lines()와 BufferedReader의 lines() 메소드를 이용하여 문자 파일의 내용을 스트림을 통해 행 단위로 읽고 콘솔에 출력합니다.

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.nio.charset.Charset;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.stream.Stream;

public class FromFileContentExample {

    public static void main(String[] args) throws IOException {

        // 파일의 경로 정보를 가지고 있는 Path 객체 생성
        Path path = Paths.get("/Users/limjun-young/workspace/privacy/linedata.txt");
        Stream<String> stream;

        //Files.Line() 메소드 이용
        stream = Files.lines(path, Charset.defaultCharset());
        stream.forEach(System.out :: println);
        System.out.println();

        //BufferedReader의 lines() 메소드 이용
        File file = path.toFile();
        FileReader fileReader = new FileReader(file);
        BufferedReader bufferedReader = new BufferedReader(fileReader);
        stream = bufferedReader.lines();
        stream.forEach(System.out :: println);

    }

}

실행 결과

스크린샷 2019-12-04 오전 12 19 35

디렉토리부터 스트림 얻기

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.stream.Stream;

public class FromDirectoryExample {
    public static void main(String[] args) throws IOException {
        Path path = Paths.get("/Users/limjun-young/workspace/privacy");
        Stream<Path> stream = Files.list(path);
        stream.forEach(p -> System.out.println(p.getFileName()));

    }
}

실행 결과

스크린샷 2019-12-04 오전 12 27 44

스트림 파이프라인

대량의 데이터를 가공해서 축소하는 것을 일반적으로 리덕션이라고 합니다. 데이의 합계, 평균값, 카운팅, 최대값, 최소값 등이 대표적인 리덕션의 결과물이라고 볼 수 있습니다. 그러나 컬렉션의 요소를 리덕션의 결과물로 바로 집계할 수 없을 경우에는 집계하기 좋도록 필터링, 매핑, 정렬, 그룹핑 등의 중간 처리가 필요합니다.

스크린샷 2019-12-04 오전 12 42 08

중간 스트림이 생성될 때 요소들이 바로 중간처리(필터링, 매핑, 정렬)되는 것이 아니라 최종 처리가 시작되기 전까지 중간 처리는 지연 됩니다. 최종 처리가 시작되면 비로소 컬렉션 요소가 하나씩 중간 스트림에서 처리되고 최종 처리까지 오게 됩니다.

Stream 인터페이스에는 필터링, 매핑, 정렬 등의 많은 중간 처리 메소드가 있습니다. 이 메소드들은 중간 처리된 스트림을 리턴합니다. 그리고 이 스트림에서 다시 중간 처리 메소드를 호출해서 파이프라인을 형성하게 됩니다. 예를 들어 회원 컬렉션에서 남자만 필터링하는 중간 스트림을 연결하고, 다시 남자의 나이로 매핑하는 스트림을 연결한 후, 최종 남자 평균 나이를 집계한 다면 다음 그림처럼 파이프라인이 형성됩니다.

스크린샷 2019-12-04 오전 12 50 08

// 스트림 파이프 라인
import java.util.Arrays;
import java.util.List;

public class StreamPipelinesExample {

    public static void main(String[] args) {
        List<Member> members = Arrays.asList(
                new Member("홍길동", Member.MALE, 30),
                new Member("김나리", Member.FEMALE, 20),
                new Member("신용권", Member.MALE, 45),
                new Member("박수미", Member.FEMALE, 27)
        );

        double ageAvg = members.stream()  
                .filter(m -> m.getSex() == Member.MALE) 
                .mapToInt(Member::getAge)
                .average()
                .getAsDouble();

        System.out.println("남자 평균 나이: " + ageAvg);
    }
}


// 회원 클래스
public class Member {

    public static int MALE = 0;
    public static int FEMALE = 1;

    private String name;
    private int sex;
    private int age;

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

    public int getSex() {
        return sex;
    }

    public int getAge() {
        return age;
    }
}
double ageAvg = members.stream() <- 오리지날 스트림
 .filter(m -> m.getSex() == Member.MALE)  <- 중간 처리 스트림
               .mapToInt(Member::getAge)  <- 중간 처리 스트림
               .average()
               .getAsDouble();            <- 최종 처리 

filter(m -> m.getSex() == Member.MALE)는 남자 Member 객체를 요소로 하는 새로운 스트림을 생성합니다. mapToInt(Member :: getAge())는 Member 객체를 age 값으로 매핑해서 age를 요소로 하는 새로운 스트림을 생성합니다. average() 메소드는 age 요소들의 평균을 OptionalDuble에 저장합니다. OptionalDouble에서 저장된 평균값을 읽으려면 getAsDouble() 메소드를 호출하면 됩니다.

중간 처리 메소드와 최종 처리 메소드를 쉽게 구분하는 방법은 리턴 타입을 보면 됩니다. 리턴 타입이 스트림이면 중간 처리 메소드이고, 기본 타입이거나 OptionalXXX라면 최종 처리 메소드 입니다. 소속된 인터페이스에서 공통의 의미는 Stream, IntStream, LongStream, DoubleStream에서 모두 제공된다는 뜻입니다.

필터링(distinct(), filter())

필터링은 중간 처리 기능으로 요소를 걸러내는 역할을 합니다. 필터링 메소드인 distinct()와 filter()메소드는 모든 스트림이 가지고 있는 공통 메소드 입니다.

distinct() 메소드는 중복을 제거하는데, Stream의 경우 Object.equals(Object)가 true이면 동일한 객체로 판단하고 중복을 제거합니다. IntStream, LongStream, DoubleStream은 동일값일 경우 중복을 제거합니다.

아래 예제는 이름 List에서 중복된 이름을 제거하고 출력합니다. 그리고 성이 "신"인 이름만 필터링해 서 출력합니다.

import java.util.Arrays;
import java.util.List;

public class FilteringExample {

    public static void main(String[] args) {
        List<String> names = Arrays.asList(
                "홍길동", "신용권", "김자바", "신용권", "신민철"
        );

        names.stream()
                .distinct()
                .filter(s -> s.startsWith("신"))
                .forEach(System.out::println);
    }

}

매핑(flatMapXXX(), mapXXX(), asXXXStream(), boxed())

매핑은 중간 처리 기능으로 스트림의 요소를 다른 요소로 대체하는 작업을 말합니다.
스트림에서 제공하는 매핑 메소드는 flatXXX()와 mapXXX(),그리고 asDoubleStream(),asLongStream(), boxed()가 있습니다.

flatMapXXX() 메소드

flatMapXXX() 메소드는 요소를 대체하는 복수 개의 요소들로 구성된 새로운 스트림을 리턴합니다.

Untitled Diagram

아래 예제는 입력된 데이터들이 List에 저장되어 있다고 가정하고, 요소별로 단어를 뽑아 단어 스트림으로 재생성합니다. 만약 입력된 데이터들이 숫자라면 숫자를 뽑아 숫자 스트림으로 재생성합니다.

import java.util.Arrays;
import java.util.List;

public class FlatMapExample {
    public static void main(String[] args) {
        List<String> inputList1 = Arrays.asList("java8 lamda", "stream mapping");


        inputList1.stream()
                  .flatMap(data -> Arrays.stream(data.split(" ")))
                  .forEach(System.out :: println);


        List<String> inputList2 = Arrays.asList("10, 20, 30", "40, 50, 60");

        inputList2.stream()
                  .flatMapToInt(data -> {
                      String[] strArr = data.split(",");
                      int[] intArr = new int[strArr.length];
                      for (int i = 0; i < strArr.length; i++) {
                          intArr[i] = Integer.parseInt(strArr[i].trim());
                      }
                      return Arrays.stream(intArr);
                  }).forEach(number -> System.out.println(number));
    }

}

스트림 메소드 2편

참조: 이것이 자바다

'SpringFramework > JAVA' 카테고리의 다른 글

멀티 스레드의 개념  (0) 2019.12.30
스트림 메소드 2편  (0) 2019.12.05
람다식을 통한 메소드 참조  (0) 2019.12.03
제네릭을 사용하는 이유?  (1) 2019.12.03
프록시 패턴  (0) 2019.11.20

람다식을 이용한 메소드 참조

메소드의 참조는 말 그대로 메소드를 참조해서 매개 변수의 정보 및 리턴 타입을 알아내어, 람다식에서 불필요한 매개 변수를 제거하는 것이 목적입니다. 람다식은 종종 기존 메소드를 단순히 호출만 하는 경우가 많습니다. 예를 들어 두 개의 값을 받아 큰 수를 리턴하는 Math 클래스의 max() 정적 메소드를 호출하는 람다식은 다음과 같습니다.

(left, right) -> Math.max(left, right);

람다식은 단순히 두개의 값을 Math.max() 메소드의 매개값으로 전달하는 역할만 하기 때문에 다소 불편해 보입니다. 이 경우 다음과 같이 메소드 참조를 이용하면 매우 깔끔하게 처리할 수 있습니다.

Math :: max; <- 메소드 참조

메소드의 참조도 람다식과 마찬가지로 인터페이스의 익명 구현 객체로 생성되므로 타겟 타입인 인터페이스의 추상 메소드가 어떤 매개 변수를 가지고, 리턴 타입이 무엇인가에 따라 달라집니다. IntBinaryOperator 인터페이스는 두 개의 int 매개값을 받아 int 값을 리턴하므로 Math :: max 메소드 참조를 대입 할 수 있습니다.

// 메소드 참조 
IntBinaryOperator operator = Math :: max;
System.out.println(operator.applyAsInt(1, 3));

메소드 참조는 정적 또는 인스턴스 메소드를 참조할 수 있고, 생성자 참조도 가능합니다.

정적 메소드와 인스턴스 메소드 참조

클래스 :: 메소드

인스턴스 메소드일 경우에는 먼저 객체를 생성한 다음 참조 변수 뒤에 :: 기호를 붙이고 인스턴스 메소드 이름을 기술하면 됩니다.

참조변수 :: 메소드

아래 예제는 Calculator의 정적 및 인스턴스 메소드를 참조합니다. 람다식이 메소드 참조로 대체되는 것을 기억해야 합니다.

public class ReferenceMethod {

    public static void main(String[] args) {

        IntBinaryOperator operator;

        // 정적 메소드 참조
        operator = (x, y) -> Calculator.staticMethod(x,y);
        System.out.println("결과1: " + operator.applyAsInt(2,3));

        // 함수적 인터페이스의 추상 메소드와 스펙이 같아야만 메소드 참조를 통해서 익명구현 객체 생성이 가능합니다.
        operator = Calculator ::staticMethod;
        System.out.println("결과2: " + operator.applyAsInt(2,4));

        // 인스턴스 메소드 참조
        Calculator calculator = new Calculator();
        operator = (x, y) -> calculator.instanceMethod(x, y);
        System.out.println("결과3: " + operator.applyAsInt(3, 6));

        operator = calculator :: instanceMethod;
        System.out.println("결과4: " + operator.applyAsInt(1,9));
    }
}

매개 변수의 메소드 참조

메소드는 람다식 외부의 클래스 맴버일 수도 있고, 람다식에서 제공되는 매개 변수의 맴버일 수도 있습니다. 이전 예제에서는 람다식 외부의 클래스 멤버인 메소드를 호출 하였습니다. 그러나 다음 람다식에서 제공되는 a 매개 변수의 메소드를 호출해서 b 매개 변수를 매개값으로 사용하는 경우도 있습니다.

(a,b) -> { a.instanceMethod(b); }

이것을 메소드 참조로 표현하면 아래 코드와 같습니다.

클래스 :: instanceMethod;

아래 예제는 두 문자열이 대소문자와 상관없이 동일한 알파벳으로 구성되어 있는지 비교합니다. 비교를 위해 사용된 메소드는 String의 인스턴스 메소드인 compareToIgnoreCase() 입니다. a.compareToIgnoreCase(b)를 호출될 때 사전 순으로 a가 b보다 먼저 오면 음수를, 동일하면 0을, 나중에 오면 음수를 리턴합니다. 사용된 함수적 인터페이스는 두 String 매개값을 받고 int 값을 리턴하는 ToBiFunction<String, String> 입니다.

import java.util.function.ToIntBiFunction;

public class ArgumentMethodReferencesExample {

    public static void main(String[] args) {

        ToIntBiFunction<String, String> function;

        function = (a, b) -> a.compareToIgnoreCase(b);
        print(function.applyAsInt("Java8", "JAVA8"));

        function = String::compareToIgnoreCase;
        print(function.applyAsInt("Java8", "JAVA8"));
    }

    public static void print(int order){
        if(order < 0){
            System.out.println("사전순으로 먼저 옵니다.");
        }else if(order == 0){
            System.out.println("동일한 문자열입니다.");
        }else{
            System.out.println("사전순으로 나중에 옵니다.");
        }
    }
}

생성자 참조

메소드 참조는 생성자 참조도 포함합니다. 생성자를 참조한다는 것은 객체 생성을 의미합니다. 단순히 메소드 호출로 구성된 람다식을 메소드 참조로 대치할 수 있듯이, 단순히 객체를 생성하고 리턴하도록 구성된 람다식은 생성자 참조로 대치할 수 있습니다. 아래 코드를 보면 람다식은 단순히 객체 생성 후 리턴만 합니다.

(a,b) -> { return new 클래스(a,b); }

이 경우, 생성자 참조로 표현하면 다음과 같습니다. 클래스 이름 뒤에 :: 기호를 붙이고 new 연산자를 기술하면 됩니다. 생성자가 오버로딩 되어 여러 개가 있을 경우, 컴파일러는 함수적 인터페이스의 추상 메소드와 동일한 매개 변수 타입과 개수를 가지고 있는 생성자를 찾아 실행합니다. 만약 해당 생성자가 존재하지 않으면 컴파일 오류가 발생합니다.

클래스 :: new

다음 예제는 생성자 참조를 이용해서 두가지 방법으로 Member 객체를 생성합니다. 하나는 Function<String, Member> 함수적 인터페이스의 Member apply(String) 메소드를 이용해서 Member 객체를 생성하였고, 다른 하나는 BiFunction<String, String, Member> 함수적 인터페이스의 Member apply(String, String) 메소드를 이용해서 Member 객체를 생성하였습니다. 생성자 참조는 두 가지 방법 모두 동일하지만,실행되는 Member 생성자가 다름을 볼 수 있습니다.

import java.util.function.BiFunction;
import java.util.function.Function;

public class ConstructorReferencesExample {

    public static void main(String[] args) {

        // 생성자 참조
        Function<String, Member> function1 = Member::new;
        // 매개 값 1개
        Member member1 = function1.apply("angel");

        BiFunction<String, String, Member> function2 = Member::new;
        Member member2 = function2.apply("신천사", "angerl");


        System.out.println(member1.getId());
        System.out.println(member2.getId());
    }
}

실행 결과

스크린샷 2019-12-03 오전 3 31 06

참조: 이것이 자바다

'SpringFramework > JAVA' 카테고리의 다른 글

스트림 메소드 2편  (0) 2019.12.05
스트림 처리 메소드 1편  (0) 2019.12.04
제네릭을 사용하는 이유?  (1) 2019.12.03
프록시 패턴  (0) 2019.11.20
Object- 1장 객체, 설계  (0) 2019.11.04

제네릭이란?

자바 5부터 제네릭(Generic) 타입이 새롭게 추가 되었는데, 제네릭 타입을 이용함으로써 잘못된 타입이 사용 될 수 있는 문제를 컴파일 과정에서 제거할 수 있습니다. 사실 API 문서를 볼때마다 제네릭 표현이 많기 때문에 제네릭을 이해하지 못하면 API 도큐먼트를 정확히 이해할 수 없습니다. 이러한 이유로 제네릭 타입에 대해서 알아보고 간단한 예제코드를 작성하였습니다.

제네릭은 클래스와 인터페이스, 그리고 메소드를 정의할 때 타입(type)파라미터(parameter)로 사용할 수 있도록 합니다. 타입 파라미터는 코드 작성 시 구체적인 타입으로 대체되어 다양한 코드를 생성하도록 해줍니다.

제네릭을 사용하는 이유?

  • 컴파일 시 강한 타입 체크를 할 수 있습니다.
    자바 컴파일러 코드에서 잘못 사용된 타입 때문에 발생하는 문제점을 제거하기 위해 제네릭 코드에 대한 강한 타입 체크를 합니다. 실행 시 타입 에러가 나는 것보다는 컴파일 시에 미리 타입을 강하게 체크해서 에러를 사전에 방지하는 것이 좋습니다.

  • 타입 변환을 제거합니다.
    비제네릭 코드는 불필요한 타입 변환을 하기 때문에 프로그램 성능에 악영향을 미칩니다. 다음 아래 코드를 보면 List에 문자열 요소를 저장했지만, 요소를 찾아올 때는 반드시 String으로 타입 변환을 해야합니다.

List list = new ArrayList();
list.add("hello");
String str = (String) list.get(0);

다음과 같이 제네릭 코드로 수정하면 List에 저장되는 요소를 String 타입으로 국한하기 때문에 요소를 찾아올 때 타입 변환을 할 필요가 없어 프로그램 성능이 향상됩니다.

List<String> list = new ArrayList<String>();
list.add("hello");
String str = list.get(0); // 타입 변환을 하지 않습니다.

제네릭 타입(class, interface)

제네릭 타입은 타입을 파라미터로 가지는 클래스와 인터페이스를 말합니다. 제네릭 타입은 클래스 또는 인터페이스 이름 뒤에 "<>"부호가 붙고, 사이에 타입 파라미터가 위치합니다.

ex)

public class 클래스명<T> {...}
public interface 인터페이스명<T> {...}

타입 파라미터는 변수명과 동일한 규칙에 따라 작성할 수 있지만, 일반적으로 대문자 알파벳 한 글자로 표현합니다. 제네릭 타입을 실제 코드에서 사용하려면 타입 파라미터 구체적인 타입을 지정해야 합니다.

제네릭을 이용한 Box 클래스 예제

public class Box<T>{
    // 클래스 뒤에 <T> 타입 파라미터를 명시했기 때문에 변수의 타입으로 사용 가능합니다.
    private T t; 
    public T get() { return t; }
    public void set(T t){ this.t = t; }
}

이제 구체적인 타입으로 변경하는 코드를 작성하겠습니다.

// 타입 파라미터를 String 타입으로 변경
Box<String> box = new Box<String>();

// 타입 파라미터 T는 String 타입으로 변경되어 Box 클래스의 내부는 다음과 같이 자동으로 재구성 됩니다.
public class Box<String>{
    private String t;
    public String get() { return t; }
    public void set(String t) { this.t = t; }
}

타입 파라미터 T를 Integer 타입으로 변경한다고 하면 마찬가지로 같습니다.

Box<Integer> box = new Box<Integer>();
box.set(6) // 자동 Boxing
int value = box.get(); // 자동 UnBoxing

이와 같이 제네릭은 클래스를 설계할 때 구체적인 타입을 명시하지 않고, 타입 파라미터로 대체했다가 실제 클래스가 사용될 때 구체적인 타입을 지정함으로써 타입 변환을 최소화 시킵니다.

멀티 타입 파라미터(class<K,V,...>, interface<K,V,...>)

제네릭 타입은 두개 이상의 멀티 타입 파라미터를 사용할 수 있습니다. 이 경우 각 타입 파라미터를 콤마로 구분합니다.

ex) 멀티 타입 파라미터를 가진 제네릭 타입을 정의하고 호출하는 예제

public class Product<T, M> {

    private T t;
    private M m;

    public T getT() {
        return t;
    }

    public void setT(T t) {
        this.t = t;
    }

    public M getM() {
        return m;
    }

    public void setM(M m) {
        this.m = m;
    }
}

public class GenericExample {
    public static void main(String[] args) {
        Product<Tv, String> product1 = new Product<>();

        product1.setT(new Tv("삼성전자Tv"));
        product1.setM("디젤");

        Tv tv = product1.getT();
        String name = product1.getM();

        System.out.println(tv.getName() +" " + name);
    }
}

제네릭 메소드(<T,R> R method(T t))

제네릭 메소드는 매개 타입과 리턴 타입으로 파라미터를 갖는 메소드를 말합니다. 제네릭 메소드를 선언하는 방법은 리턴 타입 앞에 <>기호를 추가하고 타입 파라미터를 기술한 다음, 리턴 타입과 매개 타입으로 타입 파라미터를 사용하면 됩니다.

public <타입 파라미터,...> 리턴타입 메소드명(매개변수,...){...}

다음 boxing() 제네릭 메소드 <> 기호 안에 타입 파라미터 T를 기술한 뒤, 매개 변수 타입으로 T를 사용했고, 리턴 타입으로 제네릭 타입 Box를 사용했습니다.

public <T> Box<T> boxing(T t) {...}

제네릭 메소드는 두가지 방식으로 호출할 수 있습니다. 코드에서 타입 파라미터의 구체적인 타입을 명시적으로 지정해도 되고, 컴파일러가 매개값의 타입을 보고 구체적인 타입을 추정하도록 할 수 도 있습니다.

리턴타입 변수 = <구체적인 타입> 메소드명(매개 값);
리턴타입 변수 = 메소드명(매개 값);

ex) 제네릭 메소드 호출 예제

public class Util {

    //제네릭 메소드 선언방법: 리턴 타입 앞에 타입파라미터 기술 후에 리턴 타입과, 매개타입으로 타입 파라미터를 사용하면 됩니다.
    public static <T> Box<T> boxing(T t){
        Box<T> box = new Box<>();
        box.set(t);
        return box;
    }
}

public class BoxingMethodExample{
    public static void main(String[] args){
        // 매개 값의 타입으로 자바 컴파일러에서 타입을 추정합니다.
        Box<Integer> box = Util.boxing(100);
        int initValue = box.get();
        System.out.println(initValue);
    }
}

다음 예제는 Util 클래스에 정적 제네릭 메소드로 compare()를 정의하고 CompareMethodExample 클래스에서 호출했습니다. 타입 파라미터는 K,V로 선언되었는데, 제네릭 타입 Pair가 K와 V를 가지고 있기 때문입니다. compare() 메소드는 두 개의 Pair을 매개값으로 받아 K와 V 값이 동일한지 검사하고 boolean 값을 리턴한다.

public class Util{
    public static <K,V> boolean compare(Pair<K,V> p1, Pair<K,V> p2){

        boolean keyCompare = p1.getKey().equals(p2.getKey());
        boolean valueCompare = p1.getValue().equals(p2.getValue());
        return KeyCompare && valueCompare;
    }
}

public class Pair<K,V> {


    private K key;
    private V value;

    public Pair(K key, V value) {
        this.key = key;
        this.value = value;
    }

    public void setKey(K key) {
        this.key = key;
    }

    public void setValue(V value) {
        this.value = value;
    }

    public K getKey() {
        return key;
    }

    public V getValue() {
        return value;
    }

}

public class CompareMethodExample{
    public static void main(String[] args){
          Pair<Integer, String> p1 = new Pair<Integer, String>(1, "사과");
          Pair<Integer, String> p2 = new Pair<Integer, String>(1, "사과");

          // 구체적 타입을 명시적으로 지정합니다.
          boolean result1 = Util.<Integer, String>compare(p1,p2);
          if(result1){
               System.out.println("논리적으로 등등한 객체입니다.");
          }else{
              System.out.println("논리적으로 등등하지 않는 객체입니다.");
          }

          Pair<String, String> pair = new Pair<>("user1","홍길동");
          Pair<String, String> pair = new Pair<>("user2","홍길동");
          // 구체적인 타입을 주정합니다.
          boolean result2 = Util.compare(p3,p4);

          f(result2){
               System.out.println("논리적으로 등등한 객체입니다.");
          }else{
              System.out.println("논리적으로 등등하지 않는 객체입니다.");
          }

    }
}

제한된 타입 파라미터(<T extends 최상위타입>)

타입 파라미터에 지정되는 구체적인 타입을 제한할 필요가 종종 있습니다. 예를 들어 숫자를 연산하는 제네릭 메소드는 매개값으로 Number 타입 또는 하위 클래스 타입(Byte, Short, Double, Long, Integer)의 인스턴스만 가져와야 합니다. 이것이 제한된 타입 파라미터가 필요한 이유입니다.

ex)

// 제한된 타입 파라미터 정의
public <T extends 상위타입> 리턴타입 메소드(매개변수,...){...}

타입 파라미터에 지정되는 구체적인 타입은 상위 타입이거나 상위 타입의 하위 또는 구현 클래스만 가능합니다.

주의할점은 메소드의 중괄호 {} 안에서 타입 파라미터 변수로 사용 가능 한 것은 상위 타입의 맴버(필드, 메소드)로 제한됩니다. 하위 타입에만 있는 필드와 메소드는 사용할 수 없습니다. 아래 코드는 숫자 타입만 구체적인 타입으로 갖는 제네릭 메소드 compare() 입니다. 두 개의 숫자 타입을 매개 값으로 받아 차이를 리턴합니다.

    // 제한된 타입 파라미터 정의 구체적인 타입을 제한하기 위해 사용합니다.
    public static <T extends Number> int compare(T t1, T t2){

        double v1 = t1.doubleValue();
        double v2 = t2.doubleValue();

        return Double.compare(v1,v2);
    }

doubleValue() 메소드는 Number 클래스에 정의되어 있는 메소드로 숫자를 double 타입으로 변환합니다. Double.compare() 메소드는 첫 번째 매개값이 작으면 -1을, 같으면 0을, 크면 1을 리턴합니다.

'SpringFramework > JAVA' 카테고리의 다른 글

스트림 처리 메소드 1편  (0) 2019.12.04
람다식을 통한 메소드 참조  (0) 2019.12.03
프록시 패턴  (0) 2019.11.20
Object- 1장 객체, 설계  (0) 2019.11.04
Stream(스트림)  (0) 2019.10.05

프록시 패턴

오늘은 스프링 AOP에 대해서 공부했던 과정들을 숙지하기 위해서 다시한번 프록시에 대해서 알아보았습니다. 프록시에 대해서 검색을 하는 도중에 프록시 패턴에 대한 포스팅을 접하게 되었고, 이 내용은 실제 AOP가 어떻게 동작하는지에 대한 메커니즘을 이해하는데 좋은 글이였다고 생각하여 다시 반복적인 코드 작성을 통하여 알아보는 시간이 였습니다.

프록시란?

프록시는 실제로 액션을 취하는 객체를 대신해서 대리자 역할을 합니다. 한마디로 실제 호출해야하는 메서드를 가지고 있는 실제 대상을 감싸고 있는 Wrapping 클래스라고 생각하시면 됩니다.

프록시 패턴을 사용하게 되면 프록시 단계에서 권한을 부여할 수 있는 이점이 생기고 필요에 따라 객체를 생성시키거나 사용하기 때문에 메모리를 절약할 수 있는 이점도 생깁니다. 프록시 패턴이 하는 일은 한마디로 자신이 보호하고 있는 객체에 대한 엑세스 권한을 제어하는 것입니다.

이렇게 함으로써 실제 인스턴스 사용 과정을 관여하고 메모리를 절약하는 방법을 코드로 살펴보겠습니다.

가장 먼저 실질적으로 사용되는 핵심 코드를 만들어보겠습니다. 하나는 인터페이스이고 하나는 인터페이스를 상속받는 클래스입니다.

인터페이스

public interface CommandExcutor {

    public void runCommand(String cmd) throws Exception;

}

인터페이스를 구현한 클래스

public class CommandExcutorImpl implements CommandExcutor {

    @Override
    public void runCommand(String cmd) throws Exception {
        Runtime.getRuntime().exec(cmd);
        System.out.println("cmd: " + cmd);
    }
}

위의 코드를 보면 인터페이스와 구현을 분리하여 작성하였고, 실질적으로 CommandExcutorImple를 호출하여 객체를 생성시키고 높은 cost의 runCommand() 메서드 작업으로 인해 메모리 낭비가 예상될 수 있습니다.

Runtime.getRuntime().exec() 메서드는 process를 실행시키거나 os를 제어할때 사용하는 클래스로만 알고 있습니다. 이 부분에 대해서는 저도 공부를 하지 않았기 때문에 따로 설명드리진 않겠습니다.

proxy class

위의 단점을 보완하기 위해 프록시 클래스를 작성하였습니다. 일단 똑같은 인터페이스를 상속받음으로 인터페이스의 일관성을 유지합니다.
그리고 생성자에서 CommandExcutorImpl 클래스를 인스턴스화 시키고, 인스턴스화 된 excutor 객체의 runCommand() 메서드를 프록시 클래스의 runCommand 메서드에서 엑세스를 결정합니다.

public class CommandExcutorProxy implements CommandExcutor {

    // isAdmin 값에 따라서 객체에 대한 엑세스 권한을 제어합니다.    
    private boolean isAdmin;
    private CommandExcutor excutor;


    public CommandExcutorProxy(String user, String pwd) {
        if ("sa1341".equals(user) && "1234".equals(pwd)) {
            isAdmin = true;
        }
        excutor = new CommandExcutorImpl();
    }


    @Override
    public void runCommand(String cmd) throws Exception {

        if (isAdmin) {
            excutor.runCommand(cmd);
        } else {
            if (cmd.trim().startsWith("rm")) {
                throw new Exception("rm is only admin");
            } else {
                excutor.runCommand(cmd);
            }
        }
    }
}

실행 클래스

public class ProxyPatternTest {

    public static void main(String[] args) {

        CommandExcutor excutor = new CommandExcutorProxy("sa1341","1111");

       try {
           excutor.runCommand("ls -al");
           excutor.runCommand("rm -rf *");
       }catch (Exception e){
           System.out.println(e.getMessage());
       }


    }
}

위에서는 일부로 패스워드를 다르게 주어서 특정 명렁어에 대해서 예외를 던지도록 작성하였습니다. rm -rf * 같이 터미널에서 디렉토리를 전부 강제 삭제하는 명령어이기 때문에 리스크가 존재하기 때문에 인증된 사용자만이 수행할 수 있도록 테스트 케이스에 넣어봤습니다.

실행 결과

스크린샷 2019-11-20 오후 7 33 15

위와 같이 프록시를 작성하면 인터페이스를 일관성있게 유지시키면서 엑세스 권한을 부여할 수 있고 더불어 메모리 절약을 할 수 있게 됩니다.

참조: https://blog.seotory.com/post/2017/09/java-proxy-pattern

'SpringFramework > JAVA' 카테고리의 다른 글

람다식을 통한 메소드 참조  (0) 2019.12.03
제네릭을 사용하는 이유?  (1) 2019.12.03
Object- 1장 객체, 설계  (0) 2019.11.04
Stream(스트림)  (0) 2019.10.05
@Annotation 이란?  (0) 2019.10.05

2019년에 조영호님께서 출판한 OBJECTS 코드로 이해하는 객체지향 설계라는 책을 사놓고... 읽지를 않다가 조금씩이라도 읽으면서 나중에 잊어버리지 않도록 하기 위해서 간단하게 1장 객체, 설계에 대해서 블로그에 포스팅을 해보았습니다.

패러다임의 시대

가장 먼저 소개하고 있는 부분이 패러다임의 대한 것입니다. 제가 생각하는 패러다임은 한 시대의 사회 전체가 공유하는 이론이나 방법, 문제 의식 등의 체계 정도로만 알고 있었는데 이 책에서는 패러다임이 어떻게 등장하였고 프로그래밍 세계에서 패러다임이 의미하는것이 무엇인지 구체적으로 설명하고 있습니다.

과거에는 표준적인 모델을 따르거나 모방하는 상황을 가르키는 매우 제한적인 상황에서만 패러다임이라는 단어를 사용했습니다.
쿤이라는 사람은 과학혁명의 구조라는 책을 세상에 내놓았는데, 이 책에는 기존의 과학사에 대한 관점을 뿌리채 흔들었습니다.
과학혁명은 과학이 단순한 계단식 발전의 형태를 이루는 것이 아니라 새로운 발견이 기존의 과학적 견해를 붕괴시키는 혁명정인 과정을 거쳐 발전해왔다고 주장했습니다.
과학혁명이란 과거의 패러다임이 새로운 패러다임에 의해 대체됨으로써 정상과학의 방향과 성격이 변하는 것을 의미합니다. 이를 패러다임(Paradigm Shift)의 전환이라고 부릅니다. 대표적인 예로는 우주를 바라보는 관점이 천동설에서 지동설로 변화한 사건이 있습니다.

이제 프로그래밍 관점에서 패러다임을 살펴보겠습니다.
프로그래밍 패러다임은 특정 시대의 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일이라고 할 수 있습니다. 간단히 말해서 우리가 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라집니다.
프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필욜한 부분에 대한 의견 충돌을 방지합니다. 또한 프로그래밍 패러다임을 교욱시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있습니다.

결국 이 책은 객체지향 패러다임에 관한 책으로써 객체지향 패러다임이 제시하는 프로그래밍 패러다임을 설명하는 것에 목적을 두고 있습니다. 또한 객체지향에 대한 다양한 오해를 제거함으로써 객체지향 프로그래밍을 하는 개발자들이 동일한 규칙과 표준에 따라 프로그램을 작성할 수 있게 할 것입니다.

티켓 판매 애플리케이션 구현하기

이 책은 이론보다 실무를 강조하는 책입니다. 그렇기 때문에 객체지향에 대한 다양한 측면을 설명하기 위해 이론보다는 코드를 작성하여 설명할 것입니다.

이번 시간에는 간단한 티켓 판매 프로그램을 작성하여 리뷰해보겠습니다.

이 프로그램은 관객이 티켓을 통해 소극장에 입장하여 연극이나 음악회를 즐길 수 있습니다. 여기에 소극장을 홍보도 겸할 겸 관람객들의 발길이 이어지도록 작은 이벤트를 기획하기로 했습니다. 이벤트의 내용은 간단하게 추첨을 통해 선정된 관람객에게 공연을 무료로 관람할 수 있는 초대장을 발송하는 것입니다.

여기서 핀트는 이벤트에 당첨된 관람객과 그렇지 못한 관램객은 다른 방식으로 극장에 입장시켜야 한다는 것입니다. 이벤트에 당첨된 관람객은 초대장을 티켓으로 교환한 후에 입장할 수 있습니다.
이벤트에 담청되지 않은 관람객은 티켓을 구매해야만 입장할 수 있습니다. 따라서 관람객을 입장시키기 전에 이벤트 당첨 여부를 확인해야 하고 이벤트 당첨자가 아닌 경우에는 티켓을 판매한 후에 입장시켜야 합니다.

먼저, 이벤트 당첨자에게 발송하는 초대장을 구현하는 것으로 시작하겠습니다.
초대장이라는 개념을 구현한 Invitation은 공연을 관람할 수 있는 초대일자를 인스턴스 변수로 포함하는 간단한 클래스입니다.

package object;

import java.time.LocalDateTime;

public class Invitation {

    private LocalDateTime when;
}

공연을 관람하기 원하는 모든 사람들은 티켓을 소지하고 있어야만 하기 때문에 Ticket 클래스도 추가합니다.

package object;

public class Ticket {

    private Long fee;

    public Long getFee(){
        return this.fee;
    }
}

이벤트 당첨자는 티켓으로 교환할 초대장을 가지고 있습니다. 이벤트에 당첨되지 않은 관람객은 티켓을 구매할 수 있는 현금을 보유하고 있을 것입니다. 따라서 관람객이 가지고 올 수 있는 소지품은 초대장, 현금, 티켓 세 가지뿐 입니다.

이제 관람객이 소지품을 보관할 Bag 클래스를 추가해봅니다. Bag 클래스는 초대장(invitation), 티켓(ticket), 현금(amount)을 인스턴스 변수로 포함합니다.
또한 초대장의 보유 여부를 판단하는 hasInvitation 메서드와 티켓의 소유 여부를 판단하는 hasTicket 메서드, 현금을 증가시키거나 감소시키는 plusAmount, minusAmount 메서드, 초대장을 티켓을오 교환하는 setTicket 메서드를 구현하고 있습니다.

package object;

public class Bag {

    private Long amount;
    private Ticket ticket;
    private Invitation invitation;

    // 이벤트 당첨자가 아닐 경우 초대장이 없고 현금만 보유하고 있기 때문에 생성자로 아래 this 키워드를 이용하여 초대장에 null값을 참조
    public Bag(Long amount){
        this(null, amount);
    }

    // 이벤트 당첨자일 경우 초대장과, 현금을 둘다 보유하고 있기 때문에 아래와 같은 생성자를 호출합니다.
    public Bag(Invitation invitation, Long amount){
        this.invitation = invitation;
        this.amount = amount;
    }

    // 초대장이 있습니까?
    public boolean hasInvitation(){
        return this.invitation != null;
    }

    // 티켓이 있습니까?
    public boolean hasTicket(){
        return this.ticket != null;
    }
    // 현금 감소
    public void minusAmount(Long amount){
        this.amount -= amount;
    }
    // 현금 증가
    public void plusAmount(Long amount){
        this.amount += amount;
    }
    //티켓 교환
    public void setTicket(Ticket ticket){
            this.ticket = ticket;
    }

}

여기서 이벤트에 당첨된 관람객의 가방 안에는 현금과 초대장이 들어있지만 이벤트에 당첨되지 않는 관람객의 경우 가방 안에는 초대장이 들어있지 않을 것입니다. Bag 인스턴스의 상태는 현금과 초대장을 함꼐 보관하거나, 초대장 없이 현금만 보관하는 두 가지 중 하나일 것 입니다.
위의 코드에서 Bag 인스턴스를 생성하는 시점에 이 제약을 강제할 수 있도록 생성자를 추가하였습니다.

다음은 관람객이라는 개념을 구현하는 Audience 클래스를 정의하였습니다. 관람객은 소지품을 보관하기 위해 가방을 소지할 수 있습니다.

package object;

public class Audience {

    private Bag bag;

    public Audience(Bag bag) {
        this.bag = bag;
    }

    public Bag getBag() {
        return bag;
    }
}

관람객이 소극장에 입장하기 위해서는 매표소에서 초대장을 티켓으로 교환하거나 구매해야 합니다. 따라서 매표소에는 관람객에게 판매할 티켓과 티켓의 판매 금액이 보관되어야 합니다. 매표소를 구현하기 위해 TicketOffice 클래스를 구현할 것 입니다.
TicketOffice는 판매하거나 교환해 줄 티켓의 목록(tickets)과 판매금액(amount)을 인스턴스 변수로 포함합니다. 티켓을 판매하는 getTicket 메서드는 편의를 위해 tickets 컬렉션에서 맨 첫번째 위치에 저장된 Ticket을 반환하는 것으로 구현했습니다. 또는 판매금액을 더하거나 차감하는 plusAmount와 minusAmount 메서드로 구현돼 있습니다.

package object;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public class TicketOffice {

    private Long amount;
    private List<Ticket> tickets = new ArrayList<>();

    public TicketOffice(Long amount , Ticket ... tickets){
        this.amount = amount;
        this.tickets.addAll(Arrays.asList(tickets));
    }


    public Ticket getTicket(){
        return this.tickets.remove(0);
    }

    public void minusAmount(Long amount){
        this.amount -= amount;
    }

    public void plusAmount(Long amount){
        this.amount += amount;
    }

}

판매원은 매표소에서 초대장을 티켓으로 교환해 주거나 티켓을 판매하는 역할을 수행합니다. 판매원을 구현한 TicketSeller 클래스는 자신이 일하는 매표소(ticketOffice)를 알고 있어야 합니다.

package object;

public class TicketSeller {

    private TicketOffice ticketOffice;

    public TicketSeller(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }

    public TicketOffice getTicketOffice() {
        return ticketOffice;
    }
}

모든 준비가 끝이 났습니다. 이제 아래의 그림처럼 클래스들을 조합해서 관람객을 소극장에 입장시키는 로직을 완성하는 일만 남았습니다.

스크린샷 2019-11-02 오전 1 15 15

소극장을 구현하는 클래스 Theater입니다. Theater 클래스가 관람객을 맞이할 수 있도록 enter 메소드를 구현합시다.

package object;

public class Theater {

    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }


    public void enter(Audience audience){

        if(audience.getBag().hasInvitation()){
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        }else {

            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);

        }
    }
}

소극장은 먼저 관람객의 가방 안에 초대장이 들어 있는지 확인합니다. 만약 초대장이 들어 있다면 이벤트에 당첨된 관람객이므로 판매원에게 받은 티켓을 관람객의 가방 안에 넣어줍니다. 가방 안에 초대장이 없다면 티켓을 판매해야 합니다. 이 경우 소극장은 관람객의 가방에서 티켓 금액만큼을 차감한 후 메표소에 금액을 증가시킵니다. 마지막으로 소극장은 관람객의 가방 안에 티켓을 넣어줌으로써 관람객의 입장 절차를 끝냅니다.

여기까지만 작성해도 프로그램 로직은 간단하고 예상했던대로 동작합니다. 하지만 안타깝게도 이 작은 프로그램은 몇가지 문제점을 가지고 있습니다.

무엇이 문제인가

로버트 마틴은 <클린 소프트웨어: 애자일 원칙과 패턴, 그리고 실천 방법>에서 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명합니다. 여기서 모듈이란 크기와 상관없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미합니다.

모든 소프트웨어 모듈에는 세가지 목적이 있습니다.

  • 첫 번째 목적은 실행 중에 제대로 동작하는 것입니다. 이것은 모듈의 존재 이유입니다.

  • 두 번째 목적은 변경을 위해 존재하는 것입니다. 대부분의 모듈은 생명주기 동안에 변경되기 때문에 간단한 작업만으로도 변경이 가능해야합니다. 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 합니다.

  • 세 번째 목적은 코드를 읽는 사람과 의사소통 하는 것입니다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 합니다. 읽는 사람과 의사소통 할 수 없는 모듈은 개선해야 합니다.

위에서 작성한 티켓 판매 프로그램은 관람객들을 입장시키는데 필요한 기능을 오류 없이 정확하게 수행하고 있습니다. 따라서 제대로 동작해야 한다는 제약은 만족합니다. 하지만 불행하게도 변경 용이성과 읽는 사람과의 의사소통이라는 목적은 만족시키지 못합니다.

예상을 빗나가는 코드

마지막에 소개한 Theater 클래스의 enter 메소드가 수행하는 일을 풀어보겠습니다.

소극장은 관람객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴봅니다. 가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮깁니다. 가방 안에 초대장이 들어 있지 않다면 관람객의 가방에서 티켓 금액만큼의 현금을 꺼내 매표소에 적립한 후에 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮깁니다.

여기서 문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점입니다.
관람객의 입장에서 문제는 소극장이라는 제3자가 초대장을 확인하기 위해 관람객의 가방을 마음대로 열어 본다는데 있습니다. 만약 누군가가 허락 없이 가방 안의 내용물을 마음대로 뒤적이고 돈을 가져간다면... 어떻겠습니까.. 넋놓고 다른 사람이 저의 가방을 헤집어 넣는 것을 멍하니 바라볼 사람은 없을 것입니다.

판매원도 마찬가지 입니다. 소극장이 판매원의 허락도 없이 매표소에 보관 중인 티켓과 현금을 마음대로 접근 할 수 있기 때문입니다. 더 큰 문제는 티켓을 꺼내 관람객의 가방에 집어넣고 관람객에게서 받은 돈을 매표소에 적립하는 일을 판매원이 아닌 소극장이 수행한다는 점입니다. 판매원 입장에서는 가만히 앉아 티켓이 하나씩 사라지고 돈이 저절로 쌓이는 광경을 두 손 놓고 쳐다볼 수 밖에 없는 것입니다.

현재 위의 코드는 우리의 상식과는 다르게 너무나도 다르게 동작하기 때문에 코드를 읽는 사람과 제대로 의사소통하지 못합니다.
코드를 이해하기 어렵게 만드는 또 다른 이유는 이 코드를 이해하기 위해서는 여러가지 세부적인 내용들을 한꺼번에 기억하고 있어야 합니다. Theater의 enter 메소드를 살펴보면 Audience가 Bag을 가지고 있고, Bag 안에는 현금과 티켓이 들어 있으며 TicketSeller가 TicketOffice에서 티켓을 판매하고, TicketOffice안에 돈과 티켓이 보관돼 있다는 모든 사실을 동시에 기억하고 있어야 합니다. 이 코드는 하나의 클래스나 메서드에 너무 많은 세부사항을 다뤽 때문에 코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해해야 하는 모두에게 큰 부담을 줍니다.

하지만 가장 심각한 문제는 이것이 아닙니다. 그것은 Audience와 TicketSeller를 변경할 경우 Theater도 함께 변경해야 한다는 사실입니다.

변경에 취약한 코드

더 큰 문제는 변경에 취약하다는 것입니다. 이 코드는 관람객이 현금과 초대장을 보관하기 위해 항상 가방을 들고 다닌다고 가정합니다. 또한 판매원이 매표소에서만 티켓을 판매한다고 가정합니다. 관람객이 가방을 들고 있지 않다면 어떻게 해야할까요?
관람객이 현금이 아니라 신용카드를 이용해서 결제를 한다면 어떻게 해야할까요? 판매원이 매표소 밖에서 티켓을 판매해야 한다면 어떻게 해야할까요? 이런 가정이 깨지는 순간 모든 코드가 일시에 흔들리게 됩니다.

관람객이 가방을 들고 있다는 가정이 바뀌었다고 상상해봅시다. Audience 클래스에서 Bag을 제거해야 할뿐만 아니라 Audience의 Bag에 직접 접근하는 Theater의 enter 메소드 역시 수정해야 합니다. Theater는 관람객이 가방을 들고 있고 판매원이 매표소에서만 티켓을 판매한다는 지나치게 세부적인 사실에 의존해서 동작합니다. 이러한 세부적인 사실 중 한 가지라도 바뀌면 해당 클래스 뿐만 아니라 이 클래스에 의존하는 Theater도 함께 변경해야 합니다. 이처럼 다른 클래스가 Audience의 내부에 대해 더 많이 알면 알수록 Audience를 변경하기 어려워집니다.

이것은 객체 사이의 의존성(dependency)과 관련된 문제입니다. 문제는 의존성이 변경과 관련돼 있다는 점입니다. 의존성은 변경에 대한 영향을 암시합니다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함꼐 변경될 수 있다는 사실이 내포돼 있습니다.

그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답이 아닙니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것입니다. 따라서 우리의 목표는 애플리케이션의 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것입니다.

스크린샷 2019-11-03 오전 2 07 21

객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말합니다. 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말합니다. 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있습니다. 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워 집니다. 따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것입니다.

설계 개선하기

예제 코드는 로버트 마틴이 이야기한 세 가지 목적 중 한가지는 만족시키지만 다른 두 조건은 만족시키지 못합니다. 이 코드는 기능은 제대로 수행하지만 이해하기 어렵고 변경하기 쉽지 않습니다.

여기서 변경과 의사소통이라는 문제가 서로 엮여 있다는 점에 주목합니다. 코드를 이해하기 어려운 이유는 Theater가 관람객의 가방과 판매원의 매표소에 직접 접근하기 때문입니다. 이것은 관람객과 판매원이 자신의 일을 스스로 처리해야 한다는 우리의 직관을 벗어납니다. 다시 말해서 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것입니다. Theater가 관람객의 가방과 판매원의 매표소에 직접 접근한다는 것은 Theater가 Audience와 TicketSeller에 결합된다는 것을 의미합니다. 따라서 Audience와 TicketSeller를 변경할 때 Theater도 함꼐 변경해야 하기 때문에 전체적으로 코드를 변경하기도 어려워집니다.

해결방법은 간단합니다. Theater가 Audience와 TicketSeller에 관해 너무 세부적인 부분까지 알지 못하도록 정보를 차단하면 됩니다. 사실 관람객이 가방을 가지고 있다는 사실과 판매원이 매표소에서 티켓을 판매한다는 사실을 Theater가 알아야 할 필요가 없습니다. Theater가 원하는 것은 관람객이 소극장에 입장하는 것 뿐입니다. 따라서 관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다면 이 모든 문제를 한 번에 해결할 수 있습니다.

다시 말해서 관람객과 판매원을 자율적인 존재로 만들면 되는 것이 이 장의 핀트입니다.

자율성을 높이자

해결 방법은 Audience와 TicketSeller가 직접 Bag과 TicketOffice를 처리하는 자율적인 존재가 되도록 설계를 변경하는 것입니다.

첫 번째 단계는 Theater의 enter 메소드에서 TicketOffice에 접근하는 모든 코드를 TicketSeller 내부로 숨기는 것입니다. TicketSeller에 sellTo 메소드를 추가하고 Theater에 있던 로직을 이 메서드로 옮깁니다.

public void enter(Audience audience){

    if(audience.getBag().hasInvitation()){
        Ticket ticket = ticketSeller.getTicketOffice().getTicket();
        audience.getBag().setTicket(ticket);
    }else {
        Ticket ticket = ticketSeller.getTicketOffice().getTicket();
        audience.getBag().minusAmount(ticket.getFee());
        ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
        audience.getBag().setTicket(ticket);
    }
}
---------------------변 경 전 후 ------------------------
package object;

public class TicketSeller {

    private TicketOffice ticketOffice;

    public TicketSeller(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }

    public void sellTo(Audience audience){
        if(audience.getBag().hasInvitation()){
            Ticket ticket = ticketOffice.getTicket();
            audience.getBag().setTicket(ticket);
        }else{
            Ticket ticket = ticketOffice.getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketOffice.plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}

TicketSeller에서 getTicketOffice 메소드가 제거됐다는 사실에 주목합시다. ticketOffice의 가시성이 private이고 접근 가능한 퍼블릭 메소드가 더이상 존재하지 않기 때문에 외부에서 ticketOffice에 직접 접근할 수 없습니다.
결과적으로 ticketOffice에 대한 접근은 오직 ticketSeller 안에만 존재하게 됩니다. 따라서 TicketSeller는 ticketOffice에서 티켓을 꺼내거나 판매 요금을 적립하는 일을 스스로 수행할 수밖에 없습니다.

이처럼 개념적이거나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsulation)이라고 부릅니다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것입니다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 됩니다.

이제 Theater의 enter 메소드는 sellTo 메소드를 호출하는 간단한 코드로 변경됩니다.

package object;

public class Theater {

    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }


    public void enter(Audience audience){
        ticketSeller.sellTo(audience);
    }
}

이제는 Theater는 TicektOffice가 TicketSeller 내부에 존재한다는 사실을 알지 못합니다. Theater는 단지 ticketSeller가 sellTo 메시지를 이해하고 응답할 수 있다는 사실만 알고 있을 뿐입니다.

Theater는 오직 TicketSeller의 인터페이스(interface)에만 의존합니다. TicketSeller가 내부에 ticketOffice 인스턴스를 포함하고 있다는 사실은 구현의 영역에 속합니다. 객체를 인터페이스와 구현(implementation)으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙입니다.

스크린샷 2019-11-03 오후 2 27 13

Theater의 결합도를 낮춘 설계

위의 그림은 수정 후의 클래스 사이의 의존성을 나타낸 것입니다. Theater의 로직을 TicketSeller로 이동시킨 결과, Theater에서 TicketOffice로의 의존성이 제거됐다는 사실을 알 수 있습니다. TicketOffice와 협력하는 TicketSeller의 내부 구현이 성공적으로 캡슐화 된 것입니다.

아제 Audience의 캡슐화를 개선해야 합니다. TicketSeller는 Audience의 getBag 메소드를 호출해서 Audience 내부의 Bag 인스턴스에 직접 접근합니다. Bag 인스턴스에 접근하는 객체가 Theater에서 TicketSeller로 바뀌었을 뿐 Audience는 여전히 자율적인 존재가 아닌 것입니다.

TicketSeller와 동일한 방법으로 Audience의 캡슐화를 개선할 수 있습니다. Bag에 접근하는 모든 로직을 Audience 내부로 감추기 위해 Audience에 buy 메소드를 추가하고 TicketSeller의 sellTo 메소드에서 getBag 메소드에 접근하는 부분을 buy 메소드로 옮겨 보겠습니다.

package object;

public class Audience {

    private Bag bag;

    public Audience(Bag bag) {
        this.bag = bag;
    }

    public Bag getBag() {
        return bag;
    }

    public Long buy(Ticket ticket) {
        if (bag.hasInvitation()) {
            bag.setTicket(ticket);
            return 0L;
        } else {
            bag.setTicket(ticket);
            bag.minusAmount(ticket.getFee());
            return ticket.getFee();
        }
    }
}

변경된 코드에서 Audience는 자신의 가방 안에 초대장이 들어있는지를 스스로 확인합니다. 외부의 제3자가 자신의 가방을 열어보도록 허용하지 않습니다. Audience가 직접 Bag을 처리하기 때문에 외부에서는 더 이상 Audience가 Bag을 소유하고 있다는 사실을 알 필요가 없습니다.

이제 TicketSeller가 Audience의 인터페이스에만 의존하도록 수정하면 됩니다.TicketSeller가 buy 메서드를 호출하도록 코드를 변경하면 됩니다.

package object;

public class TicketSeller {

    private TicketOffice ticketOffice;

    public TicketSeller(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }


    public void sellTo(Audience audience){
        ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
    }

}

코드를 수정한 결과, TicketSeller와 Audience 사이의 결합도가 낮아졌습니다. 또한 내부 구현이 캡슐화 됐으므로 Audience의 구현을 수정하더라도 TicketSeller에는 영향을 미치지 않습니다.

캡슐화를 개선한 후에 가장 크게 달라진 점은 Audience와 TicketSeller가 내부 구현을 외부에 노출하지 않고 자신의 문제를 스스로 책임지고 해결한다는 것입니다.
다시 말해 자율적인 존재가 된 것입니다.

무엇이 개선됐는가

수정된 Audience와 TicketSeller는 자신이 가지고 있는 소지품을 스스로 관리합니다. 이것은 우리의 예상과도 정확하게 일치합니다. 따라서 코드를 읽는 사람과의 의사소통이라는 관점엣허 이 코드는 확실히 개선된 것으로 보입니다.
더 중요한 점은 Audience나 TicketSeller의 내부 구현을 변경하더라도 Theater를 함께 변경할 필요가 없다는 것입니다. Audience가 가방이 아니라 작은 지갑을 소지하도록 코드를 변경하고 싶으면 Audience 내부만 변경하면 됩니다.
TicketSeller가 매표소가 아니라 은행에 돈을 보관하도록 만들고 싶으면 TicketSeller 내부만 변경하면 됩니다.

어떻게 한 것인가

간단하게 판매자가 티켓을 판매하기 위해 TicketOffice를 사용하는 모든 부분을 TicketSeller 내부로 옮기고, 관람객이 티켓을 구매하기 위해 Bag을 사용하는 모든 부분은 Audience 내부로 옮겼습니다. 다시 말해 자기 자신의 문제를 스스로 해결하도록 코드를 변경하였습니다. 우리는 우리의 직관을 따랐고 그 결과로 코드는 변경이 용이하고 이해 가능학도록 수정됐습니다.

우리는 객체의 자율성을 높이는 방향으로 설계를 개선했습니다. 그 결과, 이해하기 쉽고 유연한 설계를 얻을 수 있었습니다.

캡슐화와 응집도

핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것입니다. Theater는 TicketSeller의 내부에 대해서는 전혀 알지 못합니다.단지 TicketSeller가 sellTo 메시지를 이해하고 응답할 수 있다는 사실만 알고 있을 뿐입니다. TicketSeller 역시 Audience의 내부에 대해서는 전혀 알지 못합니다. 단지 Audience가 buy 메시지에 응답할 수 있고 자신이 원하는 결과를 반환할 것이라는 사실만 알고 있을 뿐입니다.

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 윙미하는 객체를 가리켜 응집도(cohesion)가 높다고 말합니다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있다.

외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길 입니다.

절차지향과 객체지향

수정하기 전의 코드에서 Audience, TicketSeller, Bag, TicketOffice는 관람객을 입장시키는데 필요한 정보를 제공하고 모든 처리는 Theater의 enter 메소드안에 존재했습니다.

이 관점에서 Theater의 enter 메소드는 프로세스이며 Audience, TicketSeller,Bag, TicketOffice는 데이터 입니다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍이라고 부릅니다.

절차적 프로그래밍 세상에서는 데이터 변경으로 인한 영향을 지역적으로 고립시키기 어렵다는 것입니다. Audience, TicketSeller의 내부 구현을 변경하려면 Theater의 enter 메소드를 함께 변경해야 합니다. 변경은 버그를 부르고 버그에 대한 두려움은 코드를 변경하기 어렵게 만듭니다. 따라서 절차적 프로그래밍 세상은 변경하기 어려운 코드를 양산하는 경향이 있습니다.

변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계입니다. 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없습니다.

수정한 후의 코드에서는 데이터를 사용하는 프로세스가 데이터를 소유하고 있는 Audience와 TicketSeller 내부로 옮겨졌습니다. 이처럼 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 객체지향 프로그래밍이라고 부릅니다.

책임의 이동

두 방식 사이에 근본적인 차이를 만드는 것은 책임의 이동입니다. 여기서는 책임을 기능을 가리키는 객체지향 세계의 용어로 생각해도 무방합니다.

두 방식의 차이점을 가장 쉽게 이해할 수 있는 방법은 기능을 처리하는 방법을 살펴보는 것입니다.

스크린샷 2019-11-03 오후 11 29 27

책임이 중앙집중된 절차적 프로그래밍

위의 절차지향 프로그래밍 처리 흐름도 그림에서 알수 있듰이 작업 흐름이 주로 Theater에 의해 제어된다는 사실을 알 수 있습니다.
객체지향 세계의 용어를 사용해서 표현하면 책임이 Theater에 집중돼 있는 것입니다.

스크린샷 2019-11-03 오후 11 35 06

책임이 분산된 객체지향 프로그래밍

그에 반해 객체지향 설계에서는 제어 흐름이 각 객체에 적절하게 분산돼 있음을 알 수 있습니다. 다시 말해 하나의 기능을 완성하는데 필요한 책임이 여러 객체에 걸쳐 분산돼 있는 것입니다.

변경 전의 절차적 설계에서 Theater가 전체적인 작업을 도맡아 처리했습니다. 변경 후의 객체 지향 설계에서는 각 객체가 자신이 맡은 일을 스스로 처리했습니다. 다시 말해 Theater에 몰려 있던 책임이 개별 객체로 이동한 것 입니다. 이것이 바로 책임의 이동이 의미하는 것입니다.

이렇게 객체지향적으로 코드를 작성하면서 더 즐거운 일은 코드가 더 이해하기 쉬워졌다는 점입니다. TicketSeller의 책임은 티켓을 판매하는 것이고, Audience는 티켓을 사는 책임을 가졌습니다. Theater는 관람객을 입장시키는 책임을 가졌습니다. 적절한 객체에 적절한 책임을 할당하면 이해하기 쉬운 구조와 읽기 쉬운 코드를 얻게 됩니다.

설계를 어렵게 만드는 것은 의존성이라는 것을 기억해야 합니다. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것입니다. 예제코드에서 결합도를 낮추기 위해 선택한 방법은 Theater가 몰라도 되는 세부사항을 Audience와 TicketSeller 내부로 감춰 캡슐화하는 것입니다. 결과적으로 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 합니다.

더 개선할 수 있다

현재의 설계는 이전의 설계보다 분명히 좋아졌지만 아직도 개선의 여지가 있습니다. Audience 클래스를 살펴보겠습니다.

package object;

public class Audience {

    private Bag bag;

    public Audience(Bag bag) {
        this.bag = bag;
    }


    public Long buy(Ticket ticket) {
        if (bag.hasInvitation()) {
            bag.setTicket(ticket);
            return 0L;
        } else {
            bag.setTicket(ticket);
            bag.minusAmount(ticket.getFee());
            return ticket.getFee();
        }
    }
}

Audience는 분명 자율적인 존재입니다. 스스로 티켓을 구매하고 가방 안의 내용물을 직접 관리합니다. 하지만 Bag은 Audience처럼 스스로 자기 자신을 책임지지 않고 Audience에 끌려다니는 수동적인 존재입니다. 여기서... 이부분을 눈치채신다면 그대는 객체지향의.. 빡고수의 자질을 가지신겁니다.. 전 몰랐습니다.. 아직 많이 부족한걸 느끼네요

다시 Bag을 자율적인 존재로 바꿔보겠습니다. 방법은 이전과 동일합니다. Bag 내부 상태에 접근하는 모든 로직을 Bag 안으로 캡슐화해서 결합도를 낮추면 됩니다. Bag에 hold 메소드를 추가해보겠습니다.

package object;

public class Bag {

    private Long amount;
    private Ticket ticket;
    private Invitation invitation;

    // 이벤트 당첨자인지 확인하는 비즈니스 로직
    public Long hold(Ticket ticket) {

        if (hasInvitation()) {
            setTicket(ticket);
            return 0L;
        } else {
            minusAmount(ticket.getFee());
            setTicket(ticket);
            return ticket.getFee();
        }
    }

    // 초대장이 있습니까?
    private boolean hasInvitation() {
        return this.invitation != null;
    }

    // 현금 감소
    private void minusAmount(Long amount) {
        this.amount -= amount;
    }

    //티켓 교환
    private void setTicket(Ticket ticket) {
        this.ticket = ticket;
    }
}

public 메소드였던 hasInvitation, minusAmount, setTicket 메소드들은 더 이상 외부에서 사용되지 않고 내부에서만 사용되기 때문에 가시성을 private로 변경했습니다. 이 작은 메소드들은 제거하지 않고 그대로 유지한 이유는 코드의 중복을 제거하고 표현력을 높이기 위해서 입니다.

Bag의 구현을 캡술화 시켰으니 이제 Audience를 Bag의 구현이 아닌 인터페이스에만 의존하도록 수정합니다.

package object;

public class Audience {

    public Long buy(Ticket ticket) {
       return bag.hold(ticket);
    }
}

TicketSeller 역시 TicketOffice의 자율권을 침해합니다. 아래 코드에서 알 수 있듯이 현재의 TicketSeller는 TicketOffice에 있는 Ticket을 마음대로 꺼내서는 자기 멋대로 Audience에게 팔고 Audience에게 받은 돈을 마음대로 TicketOffice에 넣어 버립니다.

package object;

public class TicketSeller {

    public void sellTo(Audience audience){
        ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
    }

}

잃어버린 TicketOffice의 자율권을 찾아보겠습니다. TicketOffice에 sellTicketTo 메소드를 추가하고 TicketSeller의 sellTo 메소드의 내부 코드를 이 메소드로 옮기면 됩니다. 이제 getTicket 메서드와 plusAmount 메소드는 TicketOffice 내부에서만 사용되기 때문에 가시성을 public에서 private로 변경할 수 있습니다.

public class TicketOffice {


    public void sellTicketTo(Audience audience){
        plusAmount(audience.buy(getTicket()));

    }


    private Ticket getTicket(){
        return this.tickets.remove(0);
    }


    private void plusAmount(Long amount){
        this.amount += amount;
    }
}

TicketSeller는 TicketOffice의 sellTicketTo 메소드를 호출함으로써 원하는 목적을 달성할 수 있습니다. 좋은 소식은 이제 TicketSeller가 TicketOffice의 구현이 아닌 인터페이스에만 의존하게 됐다는 점입니다

package object;

public class TicketSeller {

    public void sellTo(Audience audience){
        ticketOffice.sellTicketTo(audience);
    }
}

하지만 여기서 끝이 아닙니다... 안타깝게도 처음에 생각했던 것만큼 만족스럽지가 않습니다. 그 이유는 TicketSeller와 Audience 사이에 의존성이 추가됐기 때문입니다. 변경 전에는 TicketOffice가 Audience에 대해 알지 못했었다는 불편한 진실이 있습니다. 변경 후에는 TicketOfffice가 Audience에게 직접 티켓을 판매하기 때문에 Audience에 관해 알고 있어야 합니다.

스크린샷 2019-11-04 오전 12 36 33

TicketOffice에서 Audience로 향하는 의존성이 추가

현재로서는 Audience에 대한 결합도와 TicketOffice의 자율성 모두를 만족시키는 방법이 잘 떠오르지 않습니다. 트레이드오프 시점이 왔습니다. 여기에서는 자율성보다는 Audience에 대한 결합도를 낮추는 것이 더 중요하다는 결론에 도달했습니다.

이 작은 예제를 통해서 두 가지 사실을 알게 돼었습니다.

  • 첫째, 어떤기능을 설계하는 방법은 한 가지 이상일 수 있습니다.
  • 둘째, 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물입니다.

설계는 균형의 예술입니다. 훌륭한 설계는 적절한 트레이드 오프의 결과물이라는 사실을 명심해야 합니다. 이러한 트레이드오프 과정이 설계를 어려우면서도 흥미진진한 작업으로 만드는 것입니다.

참조:오브젝트 코드로 이해하는 객체지향 설계

'SpringFramework > JAVA' 카테고리의 다른 글

제네릭을 사용하는 이유?  (1) 2019.12.03
프록시 패턴  (0) 2019.11.20
Stream(스트림)  (0) 2019.10.05
@Annotation 이란?  (0) 2019.10.05
클린코드 OOP의 장점  (0) 2019.10.05

스트림(Stream)

스트림은 자바 8부터 추가된 컬렉션(배열포함)의 저장 요소를 하나씩 참조해서 람다식(험수적 -스타일)으로 처리할 수 있도록 해주는 반복자이다. 스트림에 대해서 저는 전혀 몰랐었고(자랑이다…), 프로젝트를 진행하면서 구글링할때 다른 개발자분이 스트림으로 작성한 코드와 스프링 부트 책의 예제에서 잠깐 보고 말았던 것인데 따로 공부를 하면서 정말 편하게 컬렉션의 요소들을 처리 할 수 있다는게 너무 좋아서 공부를 해봤습니다.

자바7 이전까지는 List 컬렉션에서 요소를 순차적으로 처리하기 위해 Iterator 반복자를 사용하여 처리하곤 했습니다.

ex)

List<String> list = Arrays.asList("홍길동", "임준영", "자바킴");
Iterator<String> iterator = list.iterator();//반복처리를 위해 Iterator 객체를 얻어옴
while(iterator.hasNext()){ // 해당 컬렉션에 요소가 있는지 확인 있으면 true 리턴
    String name = iterator.next(); //요소를 name 변수에 저장
    System.out.println(name); 
}

위의 코드처럼 iterator.hasNext()로 컬렉션 타입에 요소가 있는지 확인하고 꺼내서 처리를 하지만 스트림을 이용하면 다음처럼 구현할 수가 있습니다.

List<String> list = Arrays.asList("홍길동", "임준영", "자바킴");
Stream<String> stream = list.stream(); //컬렉션의 stream()메소드로 스트림 객체를 얻음 
stream.forEach(name -> System.out.println(name)); //해당 메소드로 컬렉션의 요소 출력

스트림 객체의 forEach 메소드의 구현부를 보면 Consumer 함수적 인터페이스 타입의 매개값을 가집니다.
따라서, 컬렉션의 요소를 소비할 코드를 람다식으로 기술할 수 있습니다.

void forEach(Consumer<? super T> action);

스트림을 사용하기전에 함수적 인터페이스와 람다식에 대해서 간단하게 설명하자면 자바 코드를 간결하고 컬렉션의 요소를 필터링하거나 매핑해서 원하는 결과를 쉽게 집계하기 위해 만들어졌고, 이벤트 지향 프로그래밍과 병렬처리를 수행하기 위해 스트림과 마찬가지로 자바 8부터 지원하는 함수적 프로그래밍이라고 생각하면 됩니다.

  • 객체지향 언어 + 함수지향 언어 == 람다식
(s) -> System.out.println(s);  // 매개변수와 실행문으로 구성되어 있습니다.

람다식의 형태는 위의 코드처럼 매개 변수를 가진 코드 블록이지만, 런타임 시에는 구현 객체를 생성합니다.

람다식이 하나의 메소드를 정의하기 때문에 두개 이상의 추상 메소드가 선언된 인터페이스는 익명으로 구현이 불가능합니다. 그렇기 때문에 하나의 추상 메소드가 선언된 인터페이스만이 람다식의 타겟타입이 될 수 있는데, 이러한 인터페이스를 함수적 인터페이스라고 부릅니다.

자바에서 제공되는 표준 API에서 한 개의 추상 메소드를 가지는 인터페이스들은 모두 람다식을 이용해서 익명 구현 객체로 표현이 가능합니다. 자바 8부터는 빈번하게 사용되는 함수적 인터페이스는 java.util.function 표준 API 패키지로 제공합니다. 이 패키지에서 제공하는 함수적 인터페이스의 목적은 메소드 또는 생성자의 매개 타입으로 사용되어 람다식을 대입할 수 있도록 하기 위해서입니다.

스트림의 forEach 메소드의 매개값에 대해서 이해하기 위해서 뭔가를 쓰긴했는데…서론이 쓰잘대 없이 길었네요ㅎㅎ… Consumer는 함수적 인터페이스로 특징은 리턴값이 없는 accept() 메소드를 가지고 있습니다. accept()메소드는 단지 매개값을 소비하는 역할만 하는데. 소비하다는 말은 사용만 할뿐 리턴값이 없는 딱히 의미있는 건 아닙니다.

Consumer<String> consumer = t -> { t를 소비하는 실행문; }; //람다식으로 익명구현 객체 생성

대충 이런식으로 매개값을 소비합니다.

이제 본격적으로 스트림에 대해서 알아보겠습니다. 위의 Iterator를 사용한 코드와 Stream을 사용한 코드를 비교해보면 Stream을 사용하는 것이 훨씬 간결해 보입니다.

스트림의 특징

Stream은 Iterator와 비슷한 역할을 하는 반복자이지만, 람다식으로 요소 처리 코드를 제공하는 점과 내부 반복자를 사용하므로 병렬 처리가 쉽다는 점 그리고 중간 처리와 최종 처리 작업을 수행하는 점에서 많은 차이를 가지고 있습니다.

Stream이 제공하는 대부분의 요소 처리 메소드는 함수적 인터페이스 매개 타입을 가지기 때문에 람다식 또는 메소드 참조를 이용해서 요소 처리 내용을 매개값으로 전달할 수 있습니다.

아래 이해하기 쉬운 좋은 예제가 있습니다.

import java.util.Arrays;
import java.util.List;
import java.util.stream.Stream;

public class LamdaExpressionsExample {

    public static void main(String[] args) {

        List<Student> list = Arrays.asList(
                new Student("임준영",100),
                new Student("노성운",92)
        );

        Stream<Student> stream = list.stream(); //스트림 얻기
        stream.forEach(s -> {//List컬렉션에서 Student를 가져와 람다식의 매개값으로 제공.
            String name = s.getName();
            int score = s.getScore();
            System.out.println("학생이름: " + name + " " + "점수: " + score);
        });
    }
}
public class Student {

    private String name;
    private int score;

    public Student(String name, int score) {
        this.name = name;
        this.score = score;
    }

    public String getName() {
        return name;
    }

    public int getScore() {
        return score;
    }
} 

스크린샷 2019-10-05 오전 1 11 58

스트림의 강력한 장점 중 하나는 내부 반복자 패턴이다. Iterator는 컬렉션의 요소를 가져오는 것에서부터 처리하는 것까지 모두 개발자가 작성해야 하지만, 스트림은 람다식으로 요소 처리 내용만 전달할 뿐, 반복은 컬렉션 내부에서 일어납니다. 스트림을 이용하면 코드도 간결해지지만, 무엇보다도 요소의 병렬 처리가 컬렉션 내부에서 처리되므로 일석이조의 효과를 누릴수 있습니다 ㅎㅎ.

또 다른 장점은 제가 스트림에 대해서 가장 많은 매력을 느낀점인데…
중간 처리와 최종처리가 가능하다는 점입니다!!!
이게 무슨 소리냐면 스트림은 컬렉션의 요소에 대해 중간 처리와 최종 처리를 수행할 수 있는데, 중간 처리에서는 매핑, 필터링, 정렬을 수행하고 최종처리에는 반복, 카운팅, 평균, 총합 등의 집계처리를 수행합니다.

예를 들어 학생 객체를 요소로 가지는 컬렉션이 있다고 가정해봅시다. 중간 처리에서는 학생의 점수를 뽑아내고, 최정처리에서는 점수의 평균 값을 산출합니다.

스크린샷 2019-10-05 오전 1 12 09

중간처리: 학생의 개별 점수를 뽑아낸다. (Student 객체를 점수로 매핑)

최종처리: 점수의 평균값을 산출한다.(집계)

여윽시…코드로 봐봅시다.

mport java.util.Arrays;
import java.util.List;
import java.util.stream.Stream;

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

        List<Student> studentList = Arrays.asList(
          new Student("임준영", 10),
          new Student("임광빈", 20),
          new Student("박찬욱", 30)
        );

        double avg = studentList.stream()
        .mapToInt(Student::getScore)
        .average()
        .getAsDouble();  //한줄로 평균을 구하는... 스트림의 위엄....

        System.out.println("평균 점수: " + avg);
        Stream<Student> stream = studentList.stream();
        stream.forEach(s -> System.out.println(s.getName()));
    }
}

스트림과 람다식을 사용하면 정말 간결하게 해당 객체의 점수를 뽑아내서 평균을 구할 수 있습니다.

List 컬렉션의 studentList변수에는 Student 타입의 객체 요소들을 가지고 있습니다.
스트림 객체를 얻어온 다음에 체인방식으로 mapToInt 메소드를 이용하여 중간처리에서 해당객체를 score 필드값으로 매핑을 합니다.

IntStream mapToInt(ToIntFunction<? super T> mapper);

마찬가지로 해당 메소드의 구현부를 보면 함수적 인터페이스를 매개값으로 받습니다.
ToIntFunction 함수적 인터페이스는 객체 T를 매개로 받아서 int 타입으로 매핑합니다.
이런식으로 컬렉션 내부적으로 스트림이 반복처리를 하고 중간처리에서 매핑한 score 필드값들로 score의 평균값을 산출하는 과정입니다. 정말 unbelievable 합니다.

스트림에서 제공하는 메소드에 대해서 아래 URL을 참조해주세요.
스트림 처리 메소드 - https://webcoding-start.tistory.com/48

'SpringFramework > JAVA' 카테고리의 다른 글

프록시 패턴  (0) 2019.11.20
Object- 1장 객체, 설계  (0) 2019.11.04
@Annotation 이란?  (0) 2019.10.05
클린코드 OOP의 장점  (0) 2019.10.05
빌더 패턴(Builder Pattern)  (0) 2019.10.05

+ Recent posts