컬렉션 프레임 워크는 데이터 군을 저장하는 클래스를 표준화한 프레임워크로, 데이터를 저장하는 자료구조와 알고리즘을 클래스로 구현해놓은것입니다.
제네릭과 다형성을 이용한 객체지향 설계로 표준화 되어있어 사용법을 익히기도 편리하며, 재사용성이 높은 코드를 작성할 수 있다는 장점이 있습니다.

컬렉션 프레임워크 인터페이스

컬렉션 프레임 워크에는 대표적으로 다음의 3가지 인터페이스가 존재합니다.

• List
• Set
• Map

List와 Set을 구현한 컬렉션 클래스들은 공통점이 많아 공통된 부분을 Collection이라는 새로운 인터페이스로 정의하여 놓았습니다. 반면 Map을 구현한 클래스들은 전혀 다른 형태로 컬렉션을 다루기 때문에 Collection을 상속하지 않습니다.

컬렉션 프레임 워크의 구현클래스들은 인터페이스의 이름을 포함하는 명명법을 따르지만 Vector, Stack, HashTable, Properties와 같은 클래스들은 컬렉션 프레임워크 이전부터 존재하였던 것이기 때문에 컬렉션 프레임워크의 명명법을 따르지 않습니다.

자바 컬렉션 프레임워크를 사용할 때 List, Set, Map과 같은 인터페이스가 아닌 ArrayList, Vector, HashMap, HashTable과 같은 구현체로 선언할 때가 있는데 이는 객체의 결합도를 매우 강하게 유지하여 비효율적이며, 추상화에 의존해야한다는 SOLID의 DIP원칙을 위반합니다.

import java.util.*;

class Main {
    public static void main(String[] args) {
        ArrayList<Integer> list1 = new ArrayList<>();   // Bad usecase
        List<Integer> list2 = new ArrayList<>();        // Good usecase
    }
}

Vector, HashTable은 Backward Compatibility를 위해 존재하는것으로 가능하면 사용하지 않는것을 권장합니다.

Collection

Collection은 List와 Set의 조상 인터페이스로 컬렉션 클래스에 저장된 데이터를 조회하고 추가 삭제하는등의 기본적인 메서드들을 정의하고 있습니다.

contains의 경우 구현에 따라 시간복잡도가 달라집니다. ArrayList의 경우 O(n)시간에 확인하며, HashMap의 경우 O(log n)의 시간에 확인합니다.

equals의 경우 내부의 값을 비교하는데, 값의 순서가 달라도 false를 반환합니다. 따라서 값의 포함 여부를 확인하고 싶으면 contains를 사용하면 됩니다.

import java.util.*;

class Main {
    public static void main(String[] args) {
        List<Integer> list1 = new ArrayList<>();
        List<Integer> list2 = new ArrayList<>();
        List<Integer> list3 = new ArrayList<>();

        for(int i = 0; i < 10; i++) {
            list1.add(i);
            list2.add(i);
        }

        for(int i = 0; i < 8; i++) {
            list3.add(i);
        }

        list3.add(9);
        list3.add(8);

        System.out.println(list1.equals(list2));
        System.out.println(list1.equals(list3));
    }
}

List Interface

List인터페이스는 중복을 허용하고 저장순서가 유지되는 자료구조를 가집니다. Collection인터페이스를 상속합니다.

순서가 유지되는 만큼 인덱스로 데이터에 접근할 수 있는 메서드들이 존재합니다.

다음의 구현 클래스를 가집니다.

• ArrayList
• LinkedList
• Vector
• Stack

ArrayList vs LinkedList

ArrayList의 경우 저장공간이 부족하면, 현재사이즈 * 2만큼의 새로운 저장공간을 확보한 후 데이터를 추가합니다. 반면, LinkedList의 경우 저장공간을 따로 확보하는것이 아니라 새로운 노드를 생성하여 연결하는 방식입니다. 따라서 충분한 공간을 확보해 준다면 순차적인 추가/삭제는 ArrayList가 더 빠릅니다.

반면 중간의 데이터를 추가/삭제하는 경우 ArrayList는 모든 요소를 재배치해야 하기 때문에 LinkedList에 비해 속도가 느립니다.

ArrayList의 경우 사용하지 않는 공간도 할당 될 수 있기 때문에 메모리 사용이 비효율적이라는 단점이 있으며, LinkedList의 경우 각 요소들이 연결되어있는 형태이기 때문에 데이터가 많을수록 읽어오는 시간이 길어진다는 단점이 있습니다.

Stack

Stack클래스는 Vector클래스를 상속하며, Last In First Out의 자료구조입니다.

import java.util.Stack;

class Main {
    public static void main(String[] args) {
        Stack<String> animals= new Stack<>();

        animals.push("Dog");
        animals.push("Horse");
        animals.push("Cat");
        System.out.println("Stack: " + animals);

        // Search an element
        int position = animals.search("Horse");
        System.out.println("Position of Horse: " + position);
    }
}

Stack: [Dog, Horse, Cat]
Position of Horse: 2

Queue Interface

Queue인터페이스는 Collection인터페이스를 상속하며 First In First Out의 자료구조입니다.

구현체는 다음과 같습니다.

• ArrayDequeue
• LinkedList
• PriorityQueue
  • 저장한 순서에 관계없이 우선순위가 높은 것부터 꺼내는 형태로, 힙 자료구조 형태로 저장합니다.

이외에도 Queue인터페이스를 상속하는 다음과 같은 인터페이스들이 있습니다

• Deque
  • 기존의 큐와 달리 앞뒤로 삽입 삭제를 할 수 있습니다.
• BlockingQueue
• BlockingDeque

Set Interface

List인터페이스와 동일하게 Set인터페이스도 Collection인터페이스를 상속합니다. 하지만 중복 요소를 허용하지 않으며, 저장순서 또한 유지되지 않습니다.

• HashSet
  • HashSet은 Set인터페이스를 구현한 가장 대표적인 컬렉션입니다. add나 addAll메서드를 통해 새로운 요소를 추가하며, 중복된 요소를 허용하지 않기 위해 equals를 호출하여 중복된 요소가 컬렉션 내에 존재하는지 확인합니다.
  • HashSet은 저장된 순서를 유지하지 않기 때문에, 저장한 순서를 유지하고자 한다면, LinkedHashSet을 사용하여 저장순서를 유지할 수 있습니다.
• TreeSet
  • 이진 탐색 트리의 일종인 레드-블랙트리로 구현된 컬렉션 클래스 입니다.

Map Interface

Map은 key-value의 형태로 요소를 저장하는 인터페이스입니다. 중복된 key를 허용하지 않고, 각 키는 하나의 값에 대응됩니다.

Map은 다음의 5개 구현 클래스를 가집니다

• HashMap
  • 해싱을 사용하여 많은 양의 데이터를 검색하는데 좋은 성능을 보입니다.
• EnumMap
• LinkedHashMap
• WeakHashMap
• TreeMap
  • 이진 탐색트리의 형태로 탐색과 정렬에 적합한 클래스입니다.

Map은 다음과 같이 3개의 확장 인터페이스를 가집니다.

• SortedMap
• NavigableMap
• ConcurrentMap

Reference

• Java의 정석
• https://docs.oracle.com/javase/7/docs/api/
• https://www.programiz.com/java-programming

[Java] 추상클래스와 인터페이스

Goal

• 추상클래스와 인터페이스에 대한 이해

추상클래스(Abstract Class)

추상클래스는 구현부가 없어 인스턴스를 생성할 수 없고, 상속을 통한 자손클래스로만 구현이 가능합니다. 이러한 추상클래스의 존재이유는 객체지향 설계의 추상 개념과 맞닿아 있습니다.

추상 개념은 구체적인 사물들의 공통적인 특징을 파악해서 이를 하나의 개념으로 나타내는것을 말합니다. 예를들어 구, 사면체, 육면체 등과 같은 도형은 입체라는 공통적인 특징을 통해 입체도형이라는 개념으로 나타낼 수 있습니다. 하지만, 이러한 도형의 겉넓이, 부피를 구하는 구체적인 행동을 구현하고자 한다면, 도형의 형태에 따라 겉넓이와 부피를 구하는 방식이 다르기 때문에 입체도형의 입장에서는 이러한 행동을 구현하기 어렵습니다.

이렇게 각각의 도형의 상위 클래스의 입장에서 하위클래스의 구체적인 행동내용을 정의 할 수 없기 때문에 추상클래스를 사용합니다.

abstract class Figure {
    abstract int getSurfaceArea();  // 추상 메서드
    abstract int getVolume();       // 추상 메서드
}

class Ball extends Figure {
    int getSurfaceArea() { ... };   // 추상 메서드 구현
    int getVolume() { ... };        // 추상 메서드 구현
}

class Tetrahedron extends Figure {
    int getSurfaceArea() { ... };   // 추상 메서드 구현
    int getVolume() { ... };        // 추상 메서드 구현

}

추상화는 구체화와 반대되는 의미로 이해할 수 있습니다. 상속 계층도에서 상위에 위치할 수록 추상화 정도가 심해져 공통요소만 남게 되며, 하위에 위치할 수록 구체화 정도가 심해져 세분화 된다고 할 수 있습니다.

인터페이스(Interface)

추상클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 합니다. 자바는 단일 상속만을 지원하기 때문에 추상클래스를 통한 설계 방식은 새로운 타입을 정의하는데 큰 제약을 받게 됩니다.

abstract class TV {
    void show();
}

abstract class VCR {
    void scanTape();
}

class TVCR extends TV,VCR { // 이와 같은 다중 상속은 허용하지 않습니다.
    ...
}

반면 인터페이스의 경우 선언한 추상메서드를 모두 정의하고 일반 규약만 잘 지킨다면 어떤 클래스를 상속했든 같은 타입으로 취급되어 다중 상속이 가능합니다.

interface TV {
    void show();
}

interface VCR {
    void scanTape();
}

interface TVCR extends TV, VCR {

}

이러한 다중 상속의 특성 때문에 인터페이스로는 계층구조가 없는 타입 프레임 워크를 만들 수 있습니다.

다음 코드에서 가수(Singer)와 작곡가(Songwriter)는 어느 쪽이 상위 개념이라 명확하게 구분하기 어렵습니다. 이때 작곡도 하는 가수를 구현하고자 하는 경우 가수에 작곡가의 코드를 구현해도 문제되지 않지만, 다중 상속을 통해 제 3의 인터페이스를 정의할 수도 있습니다.

public interface Singer {
    AudioClip sing(Song s);
}

public interface Songwriter {
    Song compose(int chartPosition);
}

public interface SingerSongwriter extends Singer, Songwriter {
    AudioClip strum();
    void actSensivitve();
}

인터페이스는 추상클래스보다 추상화 정도가 높아 일반 메서드나 멤버변수를 구성원으로 가질 수 없습니다. 오직 추상 메서드와 상수만을 허용합니다.

• 인터페이스 작성시 모든 멤버변수는 public static final이어야 하며, 이를 생략할 수 있다.
• 모든 메서드는 public abstract이어야 하며, 이를 생략할 수 있다.

추상클래스가 상속을 통해 추상 메서드를 완성하는 것 처럼, 인터페이스도 추상메서드를 구현하는 클래스를 작성해야 합니다. 다만 클래스는 확장한다는 의미의 키워드 extends를 사용하지만, 인터페이스는 구현한다는 의미의 implements를 사용합니다.

interface TV {
    void show();
}

interface VCR {
    void scanTape();
}

interface TVCR extends TV, VCR {

}

class LGTV implements TVCR {
    public void show() { ... }
    public void scanTape() { ... }
}

Reference

• Java의 정석
• Effective Java

Goal

• Facade 패턴에대한 이해
• SRP원칙에 대한 이해

SRP : 단일 책임 원칙(Single responsibility principle)

객체는 변화해야 할 단 한가지 이유만을 가져야 합니다.

쉽게 생각하면 변경이 있을때 파급 효과가 적다면, 즉 수정해야 할 코드가 적다면 단일 책임 원칙을 잘 따른것이라 볼 수 있습니다.

다음과 같이 SRP위반 사례를 예시로 SRP를 지켜야 하는 이유에 대해 알아보겠습니다.

Problem 1 : Accidental duplication

다음은 급여 애플리케이션의 Employee 클래스입니다.

Employ 클래스에는 calculatePay(), reportHours(), save() 메서드가 존재하는데 각각은 회계팀, 인사팀, 전산팀이 주로 사용합니다.

개발자가 이 세 메서드를 Employee 단일 클래스에 배치하여 서로 결합되었습니다. 이로인해 각 엑터의 결정이 다른 엑터가 의존하는 부분에 영향을 줄 수 있게 됩니다.

class Employee {
    int hour;

    // Actor : 회계팀
    public int calculatePay() { 
        ...
        regularHour();
        ... 
    }

    // Actor : 인사팀
    public void reportHours() { 
        ...
        regularHour();
        ... 
    }

    // Actor : 전산팀
    public void save() { ... }

    // 초과 업무 시간을 제외한 업무시간 계산
    private int regularHour() { ... }
}

calculatePay()와 reportHours()는 초과 업무 시간을 제외한 업무시간을 계산하는 regularHour()를 공유합니다. 회계팀에서 초과 업무 시간을 제외한 업무시간 계산 방식을 변경하고자 regularHour()를 수정하게 되면 기존의 방식을 그대로 사용하던 인사팀은 이에 영향을 받게 되고, reportHours()는 기존의 방식대로 동작하지 못하게 됩니다.

이러한 문제는 서로 다른 액터가 의존하는 코드를 너무가까이(단일 클래스)에 배치했기 때문에 발생합니다.

Problem 2 : Merge

인사팀에서는 reportHours()를 전산팀에서는 Employee의 스키마를 수정하기로 동시에 결정합니다. 각 팀의 수정사항이 반영될 때 충돌 즉, 병합이 발생하게 됩니다.

Solve

이러한 문제를 해결 하기 위해서는 데이터를 가지고 있는 EmployeeData클래스와 각 메서드를 가지고 있는 클래스로 분리하고 메서드를 가진 각 클래스들이 EmployeeData클래스를 공유하도록 하면 됩니다. 하지만 이경우 개발자가 메서드를 가진 세 클래스를 인스턴스화 하고 추적해야한다는게 단점입니다.

이경우 퍼사드 패턴(Facade Pattern)을 적용하여 클래스의 생성하여 인스턴스의 생성을 위임할 수 있습니다. 퍼사드 패턴은 서브 클래스간의 통합 인터페이스를 제공하는 역할로 클라이언트는 퍼사드 객체에서 제공하는 메서드를 호출함으로써 복잡한 서브클래스 사용을 간편하게 할 수 있습니다.

class EmployeeData {
    //data(공유자원)
    int hour;

    private EmployeeData() {
        this.hour = 0;
    }

    private static class LazyHolder {
        static final EmployeeData EMPLOYEE_DATA = new EmployeeData();
    }

    public static EmployeeData getInstance() {
        return LazyHolder.EMPLOYEE_DATA;
    }
}

class PayCalculator {
    final EmployeeData data = EmployeeData.getInstance();

    void calculatePay() {
        // 예제 코드
        data.hour += 1;
    }
}

class HourReporter {
    final EmployeeData data = EmployeeData.getInstance();

    void reportHours() {
        // 예제 코드
        data.hour += 1;
    }
}

class EmployeeSaver {
    final EmployeeData data = EmployeeData.getInstance();

    void save() {
        // 예제 코드
        data.hour += 1;
        System.out.println(data.hour);
    }
}

class EmployeeFacade {
    private final PayCalculator payCalculator;
    private final HourReporter hourReporter;
    private final EmployeeSaver employeeSaver;

    public EmployeeFacade() {
        payCalculator = new PayCalculator();
        hourReporter = new HourReporter();
        employeeSaver = new EmployeeSaver();
    }

    public void calculatePay() {
        payCalculator.calculatePay();
    }

    public void reportHour() {
        hourReporter.reportHours();
    }

    public void save() {
        employeeSaver.save();
    }
}

public class Facade {
    public static void main(String[] args) {
        EmployeeFacade employeeFacade = new EmployeeFacade();

        employeeFacade.calculatePay();
        employeeFacade.reportHour();
        employeeFacade.save();
    }
}

Singleton pattern을 적용하여 공유자원인 EmployeeData에 대한 thread-safety를 확보하였고, EmployeeFacade 클래스를 통해 객체의 생성을 위임하여 개발자가 메서드를 가진 세 클래스에 대한 인스턴스화를 하지 않아도 되도록 설계를 하였습니다.

다만 이러한 Facade 패턴을 관련 없는 메소드를 엮기 위해 사용할 경우 God-object가 될 수 있으므로 성능향상(관련없는 객체도)과 유지보수성(관련있는 객체만)의 Trade-off를 잘 고려하여 사용하여야 합니다.

Reference

• https://refactoring.guru/design-patterns/facade
• Clean Architecture