728x90

오랜만에 디자인 패턴 글을 포스팅한다.

한동안 회사의 프로젝트 프로토타입을 만드는 것과 새로운 라이브러리를 사용법을 익히고 하느라 정신없이 하루하루 지나갔던것 같고 그에따라 포스팅이 늦어진 점을 되게 반성하게 된다.

오늘은 디자인 패턴의 구조패턴 중 Composite pattern 에 대해 공부한 내용을 정리한다.

컴포지트란?

OOP에서 컴포지트는 하나 이상의 유사한 객체를 구성으로 설계된 객체로 모두 유사한 기능을 나타낸다.
이를 통해 객체 그룹을 조작하는 것처럼, 단일 객체를 조작할 수 있다.

컴포지트 패턴은 무엇인가?

컴포지트 패턴은 클라이언트가 복합 객체(group of object)나 단일 객체를 동일하게 취급하는 것을 목적으로 한다.
여기서 컴포지트의 의도는 트리 구조로 작성하여, 전체-부분(whole-part) 관계를 표현하는 것이다.

트리 구조를 다룰 때, 프로그래머는 리프 노드와 브랜치를 구별해야한다.
여기서 코드는 많은 복잡성을 만들어 많은 에러를 초래한다.
이를 해결하기 위해서 복잡하고 원시적인 객체를 동일하게 취급하기 위한 인터페이스를 작성할 수 있다.

이러한 컴포지트 패턴은 인터페이스와 본연의 컴포지트 개념을 활용한다.

언제 사용하는가?

복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 전체-부분 관계로 정의할 수 있다.
전체 - 부분 관계의 대표적 예는 directory - file 이 존재한다.

이러한 전체 - 부분 관계를 효율적으로 정의할 때 유용하다.

  • 전체 - 부분 관계를 트리 구조로 표현하고 싶을 경우
  • 전체 - 부분 관계를 클라이언트에서 부분, 관계 객체를 균일하게 처리하고 싶을 경우

예시

컴퓨터에 추가 장치 지원하기

  • 컴퓨터 클래스 모델링
    • 키보드 : 데이터를 입력받는다.
    • 마우스 : 커서의 이동을 한다.
    • 모니터 : 처리 결과를 출력한다.
  • 컴퓨터 클래스 - 합성 관계 - 구성 장치

부품들을 일반화 시킨 ComputerDevice 클래스 정의

  • ComputerDevice 클래스는 구체적인 부품들의 공통적인 기능만 가지고 실제로 존재할 수 있는
    부품은 될 수 없어서 추상클래스로 정의한다.

  • 구체적인 부품(키보드, 마우스, 모니터) 들은 ComputerDevice의 자식 클래스로 정의한다.

  • Computer클래스는 여러개의 ComputerDevice객체를 갖는다.

  • Computer클래스도 ComputerDevice 클래스의 일종이다.

    • 그러므로 >>> Computer클래스도 ComputerDevice의 일종
    • ComputerDevice 클래스를 이용하게 되면 Client 프로그램은 KeyBoard, Mouse 등과 마찬가지로 Computer를 상용할 수 있다.

아래는 클래스들에 대한 정의 이다.

ComputerDevice.java

   public abstract class ComputerDevice {
      public abstract int getPrice();
      public abstract int getPower();
}

KeyBoard.java

public class KeyBoard extends ComputerDevice{
    private final int price;
    private final int power;

    //생성자를 통한 값 할당
    public KeyBoard(int price, int power) {
        this.price = price;
        this.power = power;
    }

    @Override
    public int getPrice() {
        return price;
    }

    @Override
    public int getPower() {
        return power;
    }
}

Monitor.java

public class Monitor extends ComputerDevice{
    private final int price;
    private final int power;

    public Monitor(int price, int power){
        this.price = price;
        this.power = power;
    }


    @Override
    public int getPrice() {
        return price;
    }

    @Override
    public int getPower() {
        return power;
    }
}

Mouse.java

public class Mouse extends ComputerDevice{
    private final int price;
    private final int power;

    public Mouse(int price, int power){
        this.price = price;
        this.power = power;
    }

    @Override
    public int getPrice() {
        return price;
    }

    @Override
    public int getPower() {
        return power;
    }
}

Computer.java

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

public class Computer extends ComputerDevice{

    private List<ComputerDevice> components = new ArrayList<ComputerDevice>();

    // ComputerDevice 객체를 Computer 클래스에 추가
    public void addComponent(ComputerDevice computerDevice){
        components.add(computerDevice);
    }

    // ComputerDevice 객체를 Computer 클래스에 제거
    public void removeComponent(ComputerDevice computerDevice){
        components.remove(computerDevice);
    }

    //전체 가격 포함하는 각 부품의 가격 합산
    @Override
    public int getPrice() {
        return components.stream().mapToInt(ComputerDevice::getPrice).sum();
    }

    //소비 전력량 합산
    @Override
    public int getPower() {
        return components.stream().mapToInt(ComputerDevice::getPower).sum();
    }
}

이 부분에서는 이해가 되기 쉽게 getPrice()getPower() 는 for문으로 이해하기 쉽게 작성할 수 있지만, 저번에 배웠던 Java8의 stream을 이용하여 ComputerDevice객체를 담은 List를 Stream을 사용하여 각각의 getPower, getPrice를 구한후 IntStream으로 변형한 다음 그것의 합계를 구하는 방식으로 구현하였다.

Client.java

public class Client {
    public static void main(String[] args) {
        //컴퓨터 부품으로 keyboard, body, monitor 객체 생성
        KeyBoard keyBoard = new KeyBoard(5, 2); //가격 5, 전력 2
        Mouse mouse = new Mouse(3, 1); //가격 3, 전력 1
        Monitor monitor = new Monitor(30, 20); //가격30, 전력 20

        //Computer 객체를 생성하고 addComponent를 통해 부품 객체 설정
        Computer computer = new Computer();
        //아래의 구문을 실행할때는
        //private List<ComputerDevice> components = new ArrayList<ComputerDevice>();
        //가 이미 Computer클래스안에 객체로 만들어져 있기 때문에 addComponent를 하게 되면
        // 생성된 List객체에 값이 하나씩 담아지게 되는 것이다.
        computer.addComponent(keyBoard);
        computer.addComponent(mouse);
        computer.addComponent(monitor);

        //컴퓨터의 가격과 전력 소비량 구하기
        int computerPrice = computer.getPrice();
        int computerPower = computer.getPower();
        System.out.println("컴퓨터 가격 : " + computerPrice);
        System.out.println("컴퓨터 전력 : " + computerPower);
    }
}
  • 결과

결과는 위와 같이 나오게 된다.

  • Computer 클래스
    • ComputerDevice의 하위 클래스면서 복수 개의 ComputerDevice를 가지도록 설계하였음.
    • addComponent() 메소드를 통해 KeyBoard, Mouse, Monitor 등을 Computer 클래스의 부품으로 설정하였다.
  • Client
    • addComponent() 메소드를 통해 부품 종류에 관계 없이 동일한 메소드로 부품을 추가할 수 있다.

Computer 클래스는 개방-폐쇄 원칙을 준수하게 되고, 새로운 부품을 추가할 때에는 ComputerDevice의 자식 클래스로 구현하면 된다.

이상으로 컴포지트 패턴에 대해 알아보았다.

728x90

'디자인패턴' 카테고리의 다른 글

Facade Pattern 적용기  (0) 2022.08.10
[Java] 디자인 패턴 - 전략 패턴  (0) 2022.08.03
[Java] 디자인 패턴 - 어댑터 패턴  (0) 2022.08.03
[Java] 디자인 패턴 - 빌더 패턴  (0) 2022.08.03
728x90

Strategy 패턴(전략 패턴)

객체들이 할 수 있는 행위 각각에 대해서 전략 클래스를 생성하고, 유사한 행위들을 캡슐화 하는 인터페이스를 정의하여, 객체의 행위를 동적으로 바꾸고 싶은 경우 직접 행위를 수정하지 않고 전략을 바꿔주기만 함으로써 행위를 유연하게 확장할 수 있는 방법을 말한다.

객체가 할 수 있는 것들을 전략으로 두고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴이다.

여러 알고리즘을 하나의 추상적인 접근점을 만들어 접근점에서 서로 교환 가능하도록 하는 패턴이라고 정의 할 수 있다.

1. 전략 패턴 사용 이유

예를 들어, 게임 캐릭터 클래스가 존재하고, 칼(Knife), 검(Sword), 도끼(Ax) 라는 클래스들이 있고, 이 클래스들은 Weapon 인터페이스를 구현했다고 해보자.
기본적으로 무기는 공격이라는 기능을 갖고있다.

코드로 표현하면 아래와 같다.

public interface Weapon {
    void attack();
}
public class Knife implements Weapon{
    @Override
    public void attack() {
        System.out.println("칼 공격");
    }
}
public class Sword implements Weapon{
    @Override
    public void attack() {
        System.out.println("검 공격");
    }
}
public class Ax implements Weapon{
    @Override
    public void attack() {
        System.out.println("도끼 공격");
    }
}

공격을 하는데 칼, 검, 도끼 고유의 공격이 있다.
기본 공격은 없고 무기를 소유했을때만 지금처럼 공격이 존재하기 때문에
null을 처리해줘야 하므로 아무것도 들고 있지 않을 때 맨손 공격을 하도록 만들었다.

public class GameCharacter {
    //접근점
    private Weapon weapon;

    //교환가능
    public void setWeapon(Weapon weapon){
        this.weapon = weapon;
    }

    public void attack() {
        if(weapon == null){
            System.out.println("맨손 공격");
        }else{
            //델리게이트(의존)
            weapon.attack();
        }
    }
}

캐릭터 라는 클래스에서 선언과 구현의 접근점을 만들어주고

무기를 세팅할수있게 setWeapon 메소드를 만들어 Weapon 인스턴스에 주입해준다.

구현만 했을때 무기를 장착해주지 않으면 nullpointerException이 발생하기 때문에
null체크를 진행하여 Weapon인터페이스의 attack()을 진행해준다.

Main.java

public class Main {
    public static void main(String[] args) {
        GameCharacter character = new GameCharacter();

        character.attack(); //맨손

        character.setWeapon(new Knife()); //칼
        character.attack();

        character.setWeapon(new Sword()); //검
        character.attack();

        character.setWeapon(new Ax()); //도끼
        character.attack();
    }
}

전략패턴의 장점은 어떠한 요구사항이 추가가 되었을때, setWeapon 같이 인스턴스 주입만 해주게 되면 다른 조건도 바로 복잡하게
구성하지 않고 구현할 수 있기 때문에 추가삭제가 용이하다 라고 생각한다.

728x90
728x90

오늘은 Java 8버전에 추가된 Optional을 알아보자.
프로그래밍을 함에 있어서 NullPointerException은 계속 만나게 되는데 이유는
null을 반환하거나, null 체크를 깜빡하고 진행하지 않았을때 두 가지로 나눌 수 있다.

메소드에서 작업 중에 특별한 상황에서 값을 제대로 반환할 수 없는 경우 선택 방법

  • 예외처리를 한다.(비싸다, stackTrace를 사용)
  • null을 그대로 반환. (비용에는 문제가 없지만, 그 코드를 사용하는 클라이언트에서 주의해서 사용해야한다)
  • Optional을 반환한다.(Java 8버전부터) 클라이언트의 코드에게 명시적으로 빈 값일 수도 있다는 것을 알려주고, 빈 값인 경우 처리를 강제함)

Optional이란?

오직 값 한 개가 들어있을 수도 없을 수도 있는 컨테이너이다.

주의할 점

  • 반환값으로만 쓰기를 권장한다. (메소드 매개변수 타입, 맵의 키 타입, 인스턴스 필드 타입으로 쓰지 말자)
  • Optional을 반환하는 메소드에서 null을 반환하지 말자.
  • primitive 타입용 Optional은 따로 있다. OptionalInt, OptionalLong, ...
  • Collection, Map, Stream, Array, Optional은 Optional로 감싸지 말 것

Optional 변수 선언하기

Optional은 제네릭을 제공하기 때문에, 변수를 선언할 때 명시한 타입 인자에 따라 감쌀 수 있는 객체의 타입이 결정된다.

Optional<Integer> number; //Integer 타입의 객체를 감쌀 수 있는 Optional 타입의 변수
Optional<String> ss;       //String 타입의 객체를 감쌀 수 있는 Optional타입 변수

Optional 객체 생성하기

  • Optional.of()
  • Optional.ofNullable()
  • Optional.empty()

Optional.empty()

null을 담고 있는(비어있는) Optional 객체를 생성한다. 이 비어있는 객체는 Optional 내부적으로 미리 생성해놓은 싱글톤 인스턴스이다.

Optional<Integer> number = Optional.empty();

Optional.of(value)

null이 아닌 객체를 담고 있는 Optional객체를 생성한다. null이 넘어올 경우, NullPointerException을 뱉기 때문에 주의하여야 한다.

Optional<Integer> number = Optional.of(1);

Optional.ofNullable()

null인지 아닌지 확신할 수 없는 객체를 담고 있는 Optional 객체 생성. empty()of()를 합쳐놓은 메소드라고 생각하면 편할 것 같다. null일 경우 NullPointerException을 뱉지 않고 empty()와 동일하게 비어 있는 Optional 객체를 얻어온다. 해당 객체가 null인지 아닌지 자신이 없다면 이 메소드를 사용하는 것이 좋다.

Optional<Integer> number = Optional.ofNullable(null);

Optional에 값이 있는지 없는지 확인하기

  • Optional.isPresent()
  • Optional.isEmpty() (Java 11부터 제공)

Optional이 담고 있는 객체 접근하기

.get()은 비어있는 Optional객체에 대해서, NoSuchElementException을 뱉는다.
.orElse()는 optional이 있던 없던 무조건 후자의 기능을 수행한다.
.orElseGet()은 있으면 그대로 없다면 뒤의 supplier를 수행한다. (람다식이나 메소드 레퍼런스 사용)

OnlineClass onlineClass = optional.orElseGet(App::createNewClass);
System.out.println(onlineClass.getTitle());

.orElseThrow()는 Optional객체가 값이 있으면 그대로 가져오고 없는 경우엔 에러를 던지는 작업을 수행한다.

들어있는 값을 걸러내려면 filter()를 사용하여 조건에 맞는 객체를 반환해준다.

map()은 Optional의 타입을 변환시킨다.
if 분기문 을 없애는 것에도 일가견이 있다.
예를들어 두개의 클래스가 있다.

class Person {
// constructor, getter, setter method 생략
    private String name;
}

class House {
// constructor, getter, setter method 생략
    private Person owner;
    private String address;
}

주인이 있는데 집안에 주인이 없거나, 집 주소가 없는 경우엔 콘솔에 노출되지 않게 해야한다는 조건이 붙는다면

public static void main(String[] args){
    House house = houseService.getHouse();
    if(house.getOwner() != null && house.getOwner().getName() != null){
        System.out.println("owner : " + house.getOwner().getName());
    }
    if (house.getAddress() != null) {
        System.out.println("address: " + house.getAddress());
    }
}

이렇게 if문이 많아져서 코드가 점점 지저분하게 된다. 이럴때 map을 사용하게 되면 아래와 같다.

public static void main(String[] args){
    House house = houseService.getHouse();
    Optional.of(house)
            .map(House::getOwner)
            .map(Person::getName)
            .ifPresent(name -> System.out.println("owner : " + name);

    Optional.of(house)
            .map(House::getAddress)
            .ifPresent(address -> System.out.println("address : " + address);
}

이렇게 가독성도 좋은 복잡한 if문이 빠진 코드를 작성할 수 있다.
ifPresent()는 있다면 그 다음의 람다식을 수행하고 그렇지 않으면 실행하지 않는다.
isPresent()와는 다르다!

flatmap()은 Optional 안에 들어있는 인스턴스가 Optional인 경우에 사용하면 편리하다.
-> 다시말해 Optional이 겹쳐졌을때를 대비하여 속껍질을 한번 까준다고 생각하면 될것이다.

728x90

'Java' 카테고리의 다른 글

Mock, Mockito  (0) 2022.08.04
[Java] Enum  (0) 2022.08.03
Java Stream API  (0) 2022.08.03
[Java] 디자인패턴 - 싱글톤 패턴  (0) 2022.08.03
728x90

Java Stream API

Java Stream

Java를 다시 공부하면서 Java8에 추가된 기능중 Stream이라는 API의 기능이 있었지만 무엇인지, 어떻게 사용하는지 내가 직접 구현해보지도 않아서 그리고 막상 사용한 예들을 보니까 내 코드를 더 간결하게 만들 수 있을거란 생각이 들었다. 그래서 공부를 진행하였다.

Stream은 위에서도 말했듯, Java 8 버전 부터 추가된 기능이고, 컬렉션이나 배열 등의 저장요소를 하나씩 참조하여 함수형 인터페이스(람다식)를 적용하며 반복적으로 처리하게 해주는 기능이다.

처음에 남들과 같이 Stream이 InputStream, OutputStream같은 I/O Stream인줄 알았지만 그런 Stream은 아니다.

아래의 예를 보면 얼마나 가독성도 좋고 문법이 짧아지는지 알 수 있다.

Main.java

public class Main {
    public static void main(String[] args) {
        List<String> fruits = Arrays.asList("apple", "banana", "orange", "strawberry");

        long count = 0;
        for(String fruit : fruits){
            if(fruit.contains("p")){
                count++;
            }
        }
        System.out.println(count);


        count = fruits.stream()
                      .filter(f -> f.contains("p"))
                      .count();

        System.out.println(count);

    }
}

기존의 방법은...
fruits 라는 컬렉션이 존재하고 그 컬렉션의 요소를 for문으로 돌면서 if문을 통해 fruit요소가 p를 가지고 있다면 count 개수를 한개 늘려라라고 수행을 하는 반면
아래의 스트림방식은 fruits를 순회하면서 그 인자 가 p를 포함하고 있으면 count메소드로 1씩 증가시켜준다.
이것으로 보아 불필요한(for, if) 문법을 걷어내고 직관적이기 때문에 가독성이 좋아진다!

Stream은 Array와 Collection에 자주 쓴다.
다른데서도 쓸 수 있겠지만, 저 두개보다는 빈도가 낮기때문에 두개를 자주 쓴다고 말을 했다.

자주쓰는 것들로 Stream을 생성하는 법은 아래와 같다.

//Collection의 Stream 생성
List<String> fruits = Arrays.asList("apple", "banana", "orange", "strawberry");
fruits.stream();

//Array의 Stream 생성
int[] array = {1, 2, 3, 4, 5};
Arrays.stream(array);

//Stream을 직접 만듦
Stream<String> str = Stream.of("a", "b");

Stream의 연산

Stream이 제공하는 다양한 연산을 이용하여 복잡한 작업들을 간단히 처리할 수 있다. Stream에 정의된 메소드 중에서 데이터 소스를 다루는 작업을 연산이라고 한다.
Stream이 제공하는 연산은 중간연산최종연산이 있다.
사용법은 객체.stream().중간연산().최종연산() 순서이다.

때문에 중간연산은 계속 이어서 여러개를 수행할 수 있지만 최종연산 뒤에는 중간연산을 붙일 수 없고 그 즉시 끝나게된다.

중간 연산의 특징

  • Stream을 return한다.
  • Stateless / Stateful 연산으로 더 상세하게 구분이 가능하다. ( 대부분은 Stateless지만 distinct나 sorted처럼 이전 소스 데이터를 참조해야 하는 연산은 Stateful 이다)
  • 대표적인 예) - filter, map, sorted, skip, limit, ....

최종 연산의 특징

  • Stream을 return 하지 않는다.
  • 대표적인 예) - count, allMatch, collect, forEach, min, max, ...

사용법대로 아까의 fruits를 해보면 다음과 같다.

fruits.stream() //stream생성
      .map(a -> a.toUpperCase(Locale.ROOT)) //인자 하나마다 대문자로 변경을해주고
      .forEach(System.out::println); // 각각을 console창에 출력해달라.

Stream을 잘 알아두면 기존의 for, if를 적게쓰고 가독성을 높일 수 있으니까 더 깊이 공부하자.

728x90

'Java' 카테고리의 다른 글

[Java] Enum  (0) 2022.08.03
[Java] Optional  (0) 2022.08.03
[Java] 디자인패턴 - 싱글톤 패턴  (0) 2022.08.03
CallByValue, CallByReference 비교  (0) 2022.08.03
728x90

Adapter 패턴이란

어댑터 패턴 : 한 클래스의 인터에스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환한다. 이 패턴을 사용하면 다른 인터페이스와의 호환성 문제를 해결할 수 있다.

여기서 말하는 어댑터는 우리가 통상 사용하는 220V 전기 플러그를 여행을 갔을때 그 나라에 맞는 규격에 해당하는 전기 플러그 변환 어댑터라고 생각하면 될 것이다.

A사 B사
A사 B사
티켓선택 티켓선택
티켓출력 티켓선택
오프라인 구매 오프라인 구매
온라인 구매
메뉴 가져오기

이런 A와 B사의 티켓판매 기계가 있다고 가정을하자. A회사는 오프라인으로만 판매를 하고, B사는 온,오프 라인 나누어서 구매를 할 수 있다. 또 메뉴를 가져오는 기능도 가지고 있다.

여기서 A사의 기술을 B사가 인수를 제안하여 시스템을 통합해서 운영하자는
계획이 있다고 가정을 하고 B사가 A사의 기존 시스템 기능을 그대로 제공하면서,
B사만 몇가지 기능을 추가하려고 할때 어떻게해야하는가?

어댑터 패턴 사용 X

먼저 A사의 티켓 시스템을 인터페이스로 구현하자면 다음과 같다.

TicketA.java

public interface TicketA {
    void choice(int token);
    void print();
    void buy();
}

TicketSystemA.java

public class TicketSystemA implements TicketA{

    @Override
    public void choice(int token) {
        System.out.println("선택된 티켓 타입은 " + token + "입니다.");
    }

    @Override
    public void print() {
        System.out.println("티켓을 출력합니다.");
    }

    @Override
    public void buy() {
        System.out.println("티켓을 구매합니다.");
    }
}

다음은 B회사의 티켓 시스템이다.

TicketB.java

public interface TicketB {
    void choice(int token);
    void print();
    void buyOnOffline();
    void buyOnOnline();
    String getMenu();
}

TicketSystemB.java

public class TicketSystemB implements TicketB{

    @Override
    public void choice(int token) {
        System.out.println("선택된 티켓 타입은 " + token + "입니다.");
    }

    @Override
    public void print() {
        System.out.println("티켓을 출력합니다.");
    }

    @Override
    public void buyOnOffline() {
        System.out.println("오프라인으로 구매합니다.");
    }

    @Override
    public void buyOnOnline() {
        System.out.println("온라인으로 구매합니다.");
    }

    @Override
    public String getMenu() {
        return "메뉴정보를 가져왔습니다.";
    }
}

이 4개의 클래스와 인터페이스들로 시스템을 구현해본다.

TicketMachine.java

public class TicketMachine {
    public static void main(String[] args) {
        TicketA ticketA = new TicketSystemA();
        ticketA.choice(1);
        ticketA.buy();
        ticketA.print();

        System.out.println("----------------------");

        TicketB ticketB = new TicketSystemB();
        ticketB.choice(1);
        ticketB.buyOnOffline();
        ticketB.buyOnOnline();
        ticketB.print();
        System.out.println(ticketB.getMenu());
    }
}

이렇게 실행하여 둘다 잘 작동하는 것을 확인한다.


어댑터 패턴 사용 O

이제 아까 조건을 생각해보자.

TicketB ticketB = new TicketSystemA();

기존 B사의 시스템안에 A사의 시스템이 정상적으로 돌아가야 하기 때문에, 이것을 해결하기 위해서는 A사의 인터페이스를 G사에 맞게 다시 정의해야 한다. 하지만, 이것은 소스의 중복이 생기게 된다.

public class NewTicketSystem implements TicketB{

    @Override
    public void choice(int token) {
        System.out.println("선택된 티켓 타입은... " + token + " 입니다");

    }

    @Override
    public void print() {
        System.out.println("티켓을 출력합니다..");        

    }

    @Override
    public void buyOnOffline() {
        System.out.println("티켓을 구매합니다..");

    }

    @Override
    public void buyOnOnline() {

        throw new UnsupportedOperationException("지원되지 않는 기능");

    }

    @Override
    public String getMenu() {

        throw new UnsupportedOperationException("지원되지 않는 기능");

    }

}

B사의 인터페이스로 정의한 A사의 시스템이다. 상단부터 차례로 choice, print, buyOnOffline 메소드를 정의하기 위해서 기존의 코드를 중복한 후 사용하였다.

만약 메소드가 지금처럼 5개가 전부가 아닌 하나의 거대한 시스템이었다면 엄청난 중복과 비효율을 발생하게 될 것이다.

이럴때 사용하는 패턴이 바로 어댑터 패턴 이다❗❗

TicketAdapter.java

public class TicketAdapter implements TicketB{

    private TicketA ticket;

    public TicketAdapter(TicketA ticket){
        super();
        this.ticket = ticket;
    }

    @Override
    public void choice(int token) {
        ticket.choice(token);
    }

    @Override
    public void print() {
        ticket.print();
    }

    @Override
    public void buyOnOffline() {
        ticket.buy();
    }

    @Override
    public void buyOnOnline() {
        throw new UnsupportedOperationException("지원되지 않는 기능");
    }

    @Override
    public String getMenu() {
        throw new UnsupportedOperationException("지원되지 않는 기능");
    }
}

이런식으로 TicketB 인터페이스를 implements하여 B사의 메소드들을 전부 Override 시킨 다음
생성자로 A사의 TicketSystemA를 받고, 원래의 시스템을 그대로 유지하려는 부분에 A사의 메소드를 호출한다. 그리고 지원하지 않는 기능은 예외처리를 하여 정의하였다.

TicketMachine.java

public class TicketMachine {
    public static void main(String[] args) {
        TicketB ticketB = new TicketAdapter(new TicketSystemA());
        ticketB.choice(1);
        ticketB.buyOnOffline();
        ticketB.print();
        try{
            System.out.println(ticketB.getMenu());
        }catch (UnsupportedOperationException e){
            System.out.println("이 서비스는 다른 시스템에서 제공되는 기능입니다.");
        }
    }
}

ticketB를 TicketSystemA의 인스턴스로 생성하여 실행을 했으니 ticketB의 getMenu는 예외로 처리되어 catch부분이 실행되서 "이 서비스는 다른 시스템에서 제공되는 기능입니다." 라는 로그가 콘솔에 찍히게 될 것이다.

728x90
728x90

Builder 패턴

빌더 패턴은 생성 인자가 많을 시, 빌더 객체를 통해 구체적인 객체를 생성한다.
빌더 패턴은 추상팩토리 패턴이나 팩토리 메소드 패턴과는 조금 다르다. 빌더 패턴도 새로운 객체를 만들어 반환하는 패턴이기는 하나, 동작방식이 조금 다르다.
빌더 패턴은 생성자에 들어갈 매개 변수의 수에 관계없이 차례대로 매개 변수를 받아들이고, 모든 매개 변수를 받은 뒤에 이 변수들을 통합하여 한번에 사용한다.

  • 장점

    • 객체 생성에 필요한 파라미터의 의미를 코드 단에서 명확히 알 수 있다.
      (가독성이 좋다)
    • 생성에 필요한 파라미터가 추가될 때 마다, 생성자 오버로딩을 안해도 된다.
  • 단점

    • 추가적인 빌더 클래스를 구현해야 한다.
  • 활용

    • 생성자 인자가 많은 경우.
      User user = new User();
      user.setId();
      user.setName();
      user.setAddress();

위의 코드보다 빌더 패턴을 적용한 아래의 코드가 훨씬 가독성이 좋고, 코드를 구현하기도 편하다.

User user = new UserBuilder()
                .setId()
                .setName()
                .setAddress()
                .build();

User.java

public class User {
    private int id;
    private String name;
    private String address;

    public User(int id, String name, String address){
        this.id = id;
        this.name = name;
        this.address = address;
    }

    public int getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public String getAddress() {
        return address;
    }
}

UserBuilder.java

public class UserBuilder {
    private int id;
    private String name;
    private String address;

    public UserBuilder setId(int id) {
        this.id = id;
        return this;
    }

    public UserBuilder setName(String name) {
        this.name = name;
        return this;
    }

    public UserBuilder setAddress(String address) {
        this.address = address;
        return this;
    }

    public User build() {
        return new User(id, name, address);
    }
}

Main.java

public class main {
    public static void main(String[] args) {
        UserBuilder builder = new UserBuilder();

        User user = builder
                .setId(1)
                .setName("홍길동")
                .setAddress("서울")
                .build();

        System.out.println(user.getId() + " " + user.getName() + " " + user.getAddress());
    }
}

빌더의 set메소드들을 반환하는 인자를 자기 자신을 하기 때문에 .으로 계속 연결하여 빌더를 구성할 수 있다.
이런식으로 구현을 진행하면 User객체를 가독성이 좋고 코딩하기도 편하게 할 수 있다.

마지막으로, Builder클래스를 객체를 만들어낼 클래스와 분리할 필요는 없다. 구현하는 클래스의 내부 클래스로 Builder 클래스를 포함시켜서 진행을 해도된다.
단, 이때에는 static 메소드를 활용하여 Builder를 반환해주도록 하자.

여기까지가 빌더패턴을 정리한 것이다. 이렇게 보니 객체를 생성할때 무척 편리하고 빌더로 인해 이 코드를 처음 보는 사람도 쉽게 이해할 수 있을 것 같다고 느낀다.

728x90
728x90

팩토리 패턴

팩토리 패턴은 생성패턴(Creational Pattern) 중 하나이다.
생성 패턴은 인스턴스를 만드는 절차를 추상화하는 패턴이다.
생성 패턴에 속하는 패턴들은 객체를 생성, 합성하는 방법이나 객체의 표현방법을 시스템과 분리해준다. 생성 패턴은 시스템이 상속보다 복합방법을 사용하는 방향으로 진화되어 가면서 더 중요해지고 있다.

생성 패턴에는 중요한 이슈가 2가지 있다.

  • 생성 패턴은 시스템이 어떤 Concrete Class를 사용하는지에 대한 정보를 캡슐화한다.
  • 생성 패턴은 이들 클래스의 인스턴스들이 어떻게 만들고 어떻게 결합하는지에 대한 부분을 완전히 가려준다.

이 두가지를 정리해보면, 생성 패턴을 이용하여 무엇이 생성되고, 누가, 어떻게, 언제 육하원칙 비슷하게 결정하는데에 유연성을 확보할 수 있다.

팩토리 패턴이란?

팩토리 패턴은 객체를 생성하는 인터페이스를 미리 정의하지만, 인스턴스를 만들 클래스의 결정은 서브 클래스 쪽에서 결정하는 패턴이다. 여러개의 서브 클래스를 가진 슈퍼 클래스가 있을때, 들어오는 인자에 따라서 하나의 자식클래스의 인스턴스를 반환해주는 방식이다.
팩토리 패턴은 클래스의 인스턴스를 만드는 시점 자체를 서브 클래스로 미루는 것이다.

활용성

  • 어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때
  • 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때

Java Example

Figure.java

public interface Figure {
    void draw();
}

Circle.java

public class Circle implements Figure {

    @Override
    public void draw() {
        System.out.println("Circle의 draw 메소드");
    }

}

Rectangle.java

public class Rectangle implements Figure {

    @Override
    public void draw() {
        System.out.println("Rectangle의 draw 메소드");
    }

}

Square.java

public class Square implements Figure {

    @Override
    public void draw() {
        System.out.println("Square의 draw 메소드");
    }

}

FigureFactory

public class FigureFactory {
    public Figure getFigure(String figureType) {
        if(figureType == null) {
            return null;
        }
        if(figureType.equalsIgnoreCase("CIRCLE") {
            return new Circle();
        } else if (figureType.equalsIgnoreCase("RECTANGLE") {
            return new Rectangle();
        } else if (figureType.equalsIgnoreCase("SQUARE") {
            return new Square();
        }

        return null;
    }

}

여기서 equalsIgnoreCase()는 앞에 매개변수인 figureType의 문자열과 대소문자 구분을 하지않고 뒤의 문자열과 일치하면 true를 반환해준다.

FactoryPattern.java

public class FactoryPattern {
    public static void main(String[] args) {
        FigureFactory figureFactory = new FigureFactory();

        Figure fig1 = figureFactory.getFigure("CIRCLE");

        // Circle의 draw 메소드 호출
        fig1.draw();

        Figure fig2= figureFactory.getFigure("RECTANGLE");

        // Rectangle의 draw 메소드 호출
        fig2.draw();

        Figure fig3 = figureFactory.getFigure("SQUARE");

        // Square의 draw 메소드 호출
        fig3.draw();
    }
}

팩토리 패턴의 장점

  • 팩토리 패턴은 클라이언트 코드로부터 서브 클래스의 인스턴스화를 제거하여 서로 간의 종속성을 낮추고, 결합도를 느슨하게 하며(Loosely Coupled), 확장을 쉽게 한다.

  • 팩토리 패턴은 클라이언트와 구현 객체들 사이에 추상화를 제공한다.

팩토리 패턴의 단점

  • 새로 생성할 객체가 늘어날 때마다, Factory 클래스에 추가해야 되기 때문에 클래스가 많아짐.
728x90
728x90

@Resource, @Autowired, @Inject 차이점 정리

세 개의 어노테이션은 컨테이너에 생성된 빈(Bean) 객체를 자동으로 주입받을 수 있도록 해주는 어노테이션들이다. 주의할 점은 Bean 객체가 생성될 때 어노테이션을 스캔해서 자동 주입해준다. 일반적인 방법으로 해당 클래스의 instance를 new해서 생성하면 어노테이션은 작동하지 않는다.
그냥 Bean 설정 파일에서 하나하나 ref="다른bean" 을 생략할수 있다. 설정파일에서 Bean을 등록하지 않고 어노테이션을 통해(@Bean) 등록할 수도 있는데 원리는 같다.

@Resource

Java에서 지원하는 어노테이션이며 특정 프레임워크에 종속적이지 않다.
순서는 아래와 같다.

이름 > 타입 > @Qualifier > 성공

name 속성의 이름을 기준으로 찾는다. 없으면 타입, 없으면 @Qualifier 어노테이션의 유무를 찾고 그 어노테이션이 붙은 속성에 의존성을 주입한다.

context:annotation-config/ 구문을 꼭 xml에 추가해야한다.

사용할 수 있는 위치
멤버변수, setter메소드

@Autowired

Spring에서 지원하는 어노테이션
찾는 순서

타입 > 이름 > @Qualifier > 성공

@Autowired는 주입하려고 하는 객체의 타입이 일치하는지를 찾고 객체를 자동으로 주입한다.
만약 타입이 존재하지 않는다면 @Autowired에 위치한 속성명이 일치하는 bean을 컨테이너에서 찾는다. 그리고 이름이 없을 경우 @Qualifier 어노테이션의 유무를 찾아 그 어노테이션이 붙은 속성에 의존성을 주입해준다.

context:annotation-config/ 구문을 꼭 xml에 추가해야한다.

사용할 수 있는 위치
생성자, 멤버변수, setter 메소드에 적용이 가능함.

스프링 4.3버전 이후부터 생성자가 1개일경우 @Autowired 어노테이션을 생략이 가능하다.

@Inject

Java에서 지원하는 어노테이션이다. 특정 프레임워크에 종속적이지 않다.
찾는 순서

타입 > @Qualifier > 이름 > 실패

@Autowired와 동일하게 작동은 하지만 찾는 순서가 다르다.
@Inject를 사용하기 위해선 maven이나 gradle에 javax 라이브러리 의존성을 추가해야한다.

사용할 수 있는 위치
멤버변수, setter 메소드, 생성자, 일반 메소드에 적용 가능

@Qualifier

만약에 타입이 동일한 bean객체가 여러개가 있을시에 Spring이 Exception을 일으킨다.
스프링이 어떤 bean을 어떤것에 주입해야될지 모르기 때문에 스프링 컨테이너를 초기화하면서 에러를 발생시킨다.

  • @Autowired의 주입대상이 한개여야하는데 실제로 두개 이상의 Bean이 존재하여 주입할때 객체를 선택할 수 없다.
  • 단, @Autowired가 적용된 필드나 설정 메소드의 property 이름과 같은 이름을 가진 Bean객체가 존재할 경우에는 이름이 같은 Bean 객체를 주입받는다.

Exception
@Qualifier에 지정한 Bean 한정자 값을 갖는 Bean이 존재하지 않으면 Exception 발생함.

정리

@Resource @Autowired @Inject
범용 Java에서 지원 Spring 전용 Java에서 지원
연결방식 이름으로 매핑 타입에 맞춰서 연결 타입에 맞춰서 연결
728x90

'Spring' 카테고리의 다른 글

Spring -> Spring Boot 마이그레이션  (0) 2022.08.05
[Spring] MockMvc Bean 주입 에러  (0) 2022.08.04
[Spring] Spring Security  (0) 2022.08.03
Spring Test MockMvc 한글 깨짐 처리  (0) 2022.08.03
728x90

싱글톤패턴(Singleton Pattern)

싱글톤패턴

애플리케이션이 시작될 때 어떤 클래스가 최초 한번만 메모리를 할당하고 그 메모리에 인스턴스를 만들어 사용하는 디자인패턴이다.
생성자가 여러번 호출이 되더라도 실제로 생성되는 객체는 하나뿐이고, 최초로 생성된 이후에 호출된 생성자는 생성된 최초 객체를 반환한다.
그래서 생성자를 private로 선언하여 getInstance()로 받아서 사용한다.

싱글톤 패턴은 단 하나의 인스턴스를 생성해 사용하는 디자인 패턴이다.

이말은 인스턴스가 필요할 때마다 똑같은 인스턴스를 new해서 생성하는 것이 아닌 기존에 존재하는 인스턴스를 사용하게 하는것이다.


싱글톤패턴을 사용하는 이유

고정된 메모리 영역을 얻으면서 한번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있다. 또한 싱글톤으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기가 쉽다.
DBCP(DataBase Connection Pool)처럼 공통된 객체를 여러개 생성해서 사용해야 할 경우에 많이 쓴다.

  • 인스턴스가 절대적으로 한개만 존재하는 것을 암시할때 사용
  • 두번째 호출부터는 객체의 로딩 시간이 현저하게 줄어들어 성능이 좋아짐

싱글톤 패턴의 문제점

싱글톤에 해당하는 인스턴스가 너무 많은 일을 혼자 처리하거나 많은 데이터를 공유할 경우에 다른 클래스의 인스턴스들 간의 결합도가 높아져서 객체지향 설계 원칙인 개방-폐쇄 원칙에 위배된다.
그리고 멀티스레드 환경에서 문제가 생길 가능성이 짙다.

고전적인 방식

public class Singleton {
    private static Singleton instance;    

    private Singleton(){
        //생성자
    }

    public static Singleton getInstance(){
        if(instance == null){ // 오류 1. : 스레드가 동시에 접근했을 시 문제 발생
            instance = new Singleton(); // 2. 쓰레드가 동시 접근시 인스턴스 여러번 생성
        }
        return instance;
    }
}

보통의 Singleton 패턴 방식이다. private static으로 자기자신의 클래스를 인스턴스로 가지고 있고 getInstance() 로 대상 인스턴스를 초기화 후 반환해주는 패턴이다. 그냥 싱글스레드로 봤을때는 문제가 없을 수 있다. 하지만 멀티스레드라면 문제가 발생한다.
if(instance == null) 이 지점이 A 스레드에서 진행된 뒤에 제어권이 B 스레드로 넘어간 경우에는 또 다시 B에서 if(instance == null)이 수행되니까 if문이 다르지만 2번이 수행된다. 그래서 instance = new Singleton(); 이 생성된다. 여기서 또 다시 A 스레드로 제어권이 넘어가면 A 스레드에서 또한번 instance = new Singleton();이 수행된다. 그렇기 때문에 2개의 인스턴스가 생성되는 경우가 생기게된다.

A 스레드 : if(instance==null) -- true
B 스레드 : if(instance==null) -- true
A 스레드 : instance = new Singleton(); 인스턴스A 생성됨
B 스레드 : instance = new Singleton(); 인스턴스B 생성됨

synchronized 키워드를 사용한 Singleton 패턴

public class Singleton{
    private static Singleton instance;

    private Singleton(){

    }

    public static synchronized Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
}

synchronized를 사용하게 되면 하나의 스레드가 대상 메소드를 호출하여 시작~종료 까지 다른 스레드가 접근하지 못하도록 lock을 걸기 때문에 getInstance()에 synchronized를 사용하면 멀티 스레드 환경에서 동시접근하여 중복으로 인스턴스를 생성하는 문제를 해결할 수 있다.
그렇지만 synchronized getInstance() 의 경우 반환을 받을때 마다 스레드 동기화때문에 불필요하게 lock이 걸리게 됨 -> 비용낭비가 ↑↑↑
초기화 문제에 synchronized 를 사용했지만 초기화가 완료되고 난 후 부터는 불필요하게 lock을 걸기때문에 중복제거라는 메리트를 제외하면 다른 역할이 좋지가 않다.

이 성능 저하로 인해 완화시키기 위하여 다음과 같이 변경한다.

public class Singleton {

    private volatile static Singleton instance;

    private Singleton(){

    }

    public static Singleton getInstance(){

        if(instance == null){
            synchronized (Singleton.class) {
                if(instance == null)
                    instance = new Singleton();
            }

        }
        return instance;
    }
}

getInstance()에서 바로 synchronized를 사용하는 것이 아니라 if(instance == null)로 인스턴스가 존재하는지를 체크하고 두번째if(instance == null)에서 체크할 때, 동기화 시켜 인스턴스를 생성한다. synchronized 블럭을 처음 생성할 때 빼고는 수행하지 않기때문에 성능저하는 완화되었다.

volatile 키워드를 이용하는 경우 인스턴스는 CPU캐시에서 변수를 참조하지 않고 메인 메모리에서 변수를 참조한다. 그래서 reorder문제가 발생하지 않는다.

reorder란, 최적화를 위해 컴파일러나 JVM이 프로그램의 처리 순서를 바꾸는 것을 말한다.
프로그램의 수행 능력을 높이기 위해 널리 사용되고 있지만, 그 사실을 프로그래머가 의식하기는 어렵다. 
실제 싱글 쓰레드 프로그램에서는 reorder가 이뤄지고 있는지 판단할 수 없다.
reorder시에 예기치 못한 작동을 막기 위한 제약이 따르기 때문이다.
(사실 싱글 쓰레드 프로그램에서는 reorder로 인한 동시성 문제가 일어나지 않는다.)
그러나 멀티 쓰레드 프로그램에서는 reorder가 원인이 되어 예기치 못한 작동을 하는 경우가 있다.

이것도 완벽한 방법은 아니기에 아래의 방법을 사용한다.

Holder에 의한 초기화를 사용한 Singleton 패턴

public class Singleton{
    private Singleton(){

    }

    private static class Holder{
        public static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance(){
        return Holder.INSTANCE;
    }
}

직접적으로 동기화 문제에 대해서 문제를 회피하고자 다른 위의 방법들을 사용했지만 그만큼 복잡해졌었고 또 다른 오류가 발생할 수 있는것들을 확인하였다.
이 방법은 JVM클래스가 초기화 과정에서 보장되는 원자적 특성을 이용해 싱글톤 패턴의 초기화 문제에 대한 책임을 JVM에 떠넘긴다.
Holder안에 선언한 인스턴스가 static이기 때문에 로딩된 시점에 한번만 호출될 것이고 final을 사용하여 값이 재할당되는것을 막은 방법이다.

가장 많이 사용하고 일반적인 Singleton Pattern 사용 방법이다.

728x90

'Java' 카테고리의 다른 글

[Java] Enum  (0) 2022.08.03
[Java] Optional  (0) 2022.08.03
Java Stream API  (0) 2022.08.03
CallByValue, CallByReference 비교  (0) 2022.08.03

+ Recent posts