Collections 클래스와 Collection 인터페이스의 관계

Collections 클래스와 Collection 인터페이스는 둘다 Java의 java.util 패키지에 속하지만, 서로 다른 역할을 수행한다.

 

Collection 인터페이스

Collection은 Java 컬렉션 프레임워크의 가장 기본이 되는 인터페이스이다.

List, Set, Queue 등이 이 인터페이스를 구현하고 있다.

 

Collections 클래스

Collections는 인터페이스가 아닌 유틸리티 클래스이다.
Collection 인터페이스를 구현하는 객체들을 다루기 위한 정적 메소드(정렬, 탐색, 동기화, 변경 불가능 설정 등)를 제공한다. 말그대로 따로 구현체가 있다기보다는 특정 작업을 지원해주는 클래스인 것이다.
예를 들어, Collections.sort(), Collections.synchronizedList(), Collections.unmodifiableList()와 같은 메소드들은 컬렉션 객체들을 조작하거나 변환하는 데 사용된다.

 

Collections 클래스와 Collection 인터페이스의 관계

Collections 클래스는 Collection 인터페이스를 구현하는 다양한 객체들을 조작하는 데 사용되는 도구집이다.

Collections 클래스는 Collection 인터페이스를 직접 구현하거나 확장하지 않지만, Collection 인터페이스를 구현하는 모든 종류의 컬렉션 객체들과 상호작용한다. Collections 클래스를 통해 제공되는 메소드들은 컬렉션 데이터 구조를 더욱 효율적으로 관리할 수 있게 해주는 도구로서, 기본적인 컬렉션 작업을 단순화시키고 향상시키는 역할을 한다.

이처럼 Collections 클래스와 Collection 인터페이스는 서로 보완적인 관계를 가지며, Java 컬렉션 프레임워크 내에서 중요한 역할을 담당한다.

 

비슷한 맥락으로,

 

Arrays 유틸리티 클래스와 List 인터페이스

Maps 유틸리티 클래스와 Map 인터페이스

Sets 유틸리티 클래스와 Set 인터페이스

Streams 유틸리티 클래스와 Stream 인터페이스

Files 유틸리티 클래스와 Path 인터페이스

 

Java 에는 이러한 객체지향적 설계가 곳곳에 숨어있다.

나는 이런 패턴을 찾는 것을 무척이나 좋아한다.

 

이러한 유틸리티 클래스 - 구현체 인터페이스 관계에 대해서

OOP적 관점으로 다시 한번 살펴보자

 

 

단일 책임 원칙 (Single Responsibility Principle)

단일 책임 원칙은 Java의 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙 SOLID 에서 S에 해당하는 원칙이다. 이 원칙은 "클래스는 하나의 책임만 가져야 한다"는 원칙이다. 유틸리티 클래스는 이 원칙을 따라, Collections 클래스는 컬렉션 객체들을 조작하는 데 필요한 정적 메소드들로 구성되어 있으며, 각 메소드는 특정한 유형의 작업만을 담당합니다. 이는 메인 클래스가 비대해지는 것을 방지하고, 관련 기능들을 유지보수하기 쉽게 분리했다.

 

 

인터페이스 분리 원칙 (Interface Segregation Principle)

인터페이스 분리 원칙은 Java의 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙 SOLID 에서 I에 해당하는 원칙이다. 이 원칙은 "클라이언트는 자신이 사용하지 않는 메서드에 의존하면 안된다"는 원칙이다. 즉, 자신이 사용하는 메서드에만 의존해야 된다는 말인데, Collection 인터페이스는 기본적인 컬렉션 작업을 정의하고, 이보다 더 특화된 작업은 List, Set, Queue 등의 하위 인터페이스에서 정의합니다. 유틸리티 클래스는 이러한 인터페이스에 종속된 특화된 기능을 제공함으로써 인터페이스 분리 원칙을 강화한다.

 

 

팩토리 패턴 (Factory Pattern)

팩토리 패턴은 Java의 OOP적 설계 양식(Design Pattern) 중 하나의 패턴(양식)이다. 이 패턴은 객체 생성을 위한 인터페이스를 정의하며, 이를 통해 클라이언트가 시스템에서 사용할 객체의 클래스를 명시하지 않고 객체를 생성할 수 있도록 한다. 쉽게 말하자면, 객체 생성을 캡슐화 해서, 객체를 생성하는 코드와 사용하는 코드를 분리하는 것이다. Java의 유틸리티 클래스들은 팩토리 메소드를 제공한다. 예를 들어, Collections의 unmodifiableList나 synchronizedList와 같은 메소드는 새로운 컬렉션 객체를 생성하고 반환한다.

 

팩토리 패턴 구체적 설명 및 예시 코드

https://github.com/SMJin/JAVA-DesignPattern/tree/master/FactoryPattern

JAVA-DesignPattern/FactoryPattern at master · SMJin/JAVA-DesignPattern

 

전략 패턴 (Strategy Pattern)

전략 패턴은 Java의 OOP적 설계 양식(Design Pattern) 중 하나의 패턴(양식)이다. 이 패턴은 실행 중에 알고리즘을 선택할 수 있도록 하여 알고리즘을 클라이언트 코드로부터 분리시킨다. 유틸리티 클래스들은 이 패턴을 약간 변형된 형태로 사용할 수 있다. 예를 들어, Collections.sort() 메소드는 다양한 정렬 전략을 받아들일 수 있도록 Comparator 인터페이스를 파라미터로 사용한다.

 

전략 패턴 구체적 설명 및 예시 코드

https://github.com/SMJin/JAVA-DesignPattern/tree/master/StrategyPattern

JAVA-DesignPattern/StrategyPattern at master · SMJin/JAVA-DesignPattern

 

데코레이터 패턴 (Decorator Pattern)

데코레이터 패턴은 Java의 OOP적 설계 양식(Design Pattern) 중 하나의 패턴(양식)이다. 이 패턴은 객체에 동적으로 새로운 책임을 추가하는 방법을 제공한다. Collections 유틸리티 클래스는 이 패턴을 사용하여 기존 컬렉션 객체에 새로운 행동을 추가한다. 예를 들어, unmodifiableCollection 메소드는 주어진 컬렉션에 변경 불가능성을 추가하는 데코레이터를 제공한다.

 

데코레이터 패턴 구체적 설명 및 예시 코드

https://github.com/SMJin/JAVA-DesignPattern/tree/master/DecoratorPattern

JAVA-DesignPattern/DecoratorPattern at master · SMJin/JAVA-DesignPattern