전략 패턴은 디자인 패턴의 꽃이라 할 수 있다. 따라서 스프링을 공부하고자 하는 사람은 꼭 이해하고 넘어가야 할 부분이다. 주의깊게 보도록 해보자.

전략 패턴을 구성하는 요소는 세 가지다.

1. 전략 메소드를 가진 전략 객체
2. 전략 객체를 사용하는 컨텍스트 (전략 객체의 사용자/소비자)
3. 전략 객체를 생성해 컨텍스트에 주입하는 클라이언트

전략 패턴의 맹점은 다음과 같다. 

"전략 패턴에서 클라이언트는 다양한 전략 중 하나를 선택해 생성한 후 컨텍스트에 주입한다."

예를 들어 군인이 있다고 가정해보자. 군인은 다양한 무기중 주어진 환경에 적합한 무기를 사용할 것이다. 또한 이를 보급해주는 보급 장교가 있다고 해보자. 그럼 여기서 무기는 전략이 되고, 군인은 컨텍스트, 보급 장교는 제 3자인 클라이언트가 된다.

다음은 코드를 볼 예정인데, 다양한 전략, 무기를 공통된 방법으로 사용하기 위해서 인터페이스를 정의할 것이다.

package 전략패턴;

public interface 전략 {
    public abstract void runStrategy();
}

public class 총 implements 전략{

    @Override
    public void runStrategy() {
        System.out.println("총 : 탕탕탕");
    }
}

public class 칼 implements 전략{
    @Override
    public void runStrategy() {
        System.out.println("칼 : 슝슝");
    }
}

public class 활 implements 전략{
    @Override
    public void runStrategy() {
        System.out.println("활 : 슉 슉 슈슝");
    }
}

public class 군인 {
    void runContext(전략 strategy) {
        System.out.println("전투 시작");
        strategy.runStrategy();
        System.out.println("전투 종료");
    }
}

public class Client {
    public static void main(String[] args) {
        전략 strategy = null;
        군인 rambo = new 군인();

        strategy = new 총();
        rambo.runContext(strategy);

        strategy = new 칼();
        rambo.runContext(strategy);

        strategy = new 활();
        rambo.runContext(strategy);

    }
}

위의 코드의 흐름은 클라이언트(=보급장교)가 군인인 람보에게 총, 칼, 활을 주고 전투가 시작되고 전투가 끝나는 흐름이 된다. 위에 보면 전략인 무기가 다양하게 변경되면서 컨텍스트를 실행할 수 있게 된 것이다. 전략 패턴은 디자인 패턴의 꽃이라 했던 것처럼, 다양한 문제 상황의 해결책으로 사용된다.

혹여라도 SOLID에 대한 부분이나 이전에 디자인 패턴이 공부한 기억이 있다면, 템플릿 메소드 패턴과 유사하다는 생각이 들 수도 있다. 같은 문제에 해결책으로 템플릿 메소드 패턴과 전략 패턴을 선택하여 사용할 수 있는데 상속이라는 제한이 있는 템플릿 메소드 패턴보다는 전략 패턴을 Java 진형에서 더 많이 사용한다고 한다.

마지막 한마디로 정리하자.

"클라이언트가 전략을 생성해 전략을 실행할 컨텍스트에 주입하는 패턴"

guy-who-writes-sourcecode.tistory.com/

[객체지향 SW 설계의 원칙] ③ 인터페이스 분리의 원칙

좋은 내용이 있어 읽어보고 정리합니다. 단순한 개인 공부입니다. 잘못된 부분이 있으면 지적해주세요

인터페이스 분리 원칙?

ISP의 핵심은 '변화'가 핵심이 된다. 어떻게 변화할 것인지에 대해서 천천히 알아보자

다음과 같은 구조의 프로그램이 있다. 이 프로그램에서 제공하는 기능은 불법 결제 패턴에 해당하는 사용자 결제를 차단하고, 이를 담당자에게 메일로 리포팅하는 동작을 하게 된다.

하지만 여기서 추가적으로 SMS 리포팅 기능을 구현해야 하면 어떻게 될까?

아마도 CPRule에 메소드를 추가할 것인다. 그럼?

전혀 상관없는 클래스에게도 영향을 미치게 될 것이다. 이는 클래스의 재컴파일, 재배포 등과 같은 문제점을 야기한다.

이런 부분을 ISP를 통해서 해소할 수 있다. ISP 를 간단하게 정의하면 "클라이언트는 자기가 사용하지 않는 메소드에 의존 관계를 맺으면 안된다" 라는 것이다.

아직 한참 모자란 본인은 많은 부분에서 사용하지 않는 메소드가 있음에도 불구하고 의존 관계를 만들어서 사용했던 기억이 있다. 자 그럼 인터페이스를 사용해서 구조를 바꾸면 어떻게 될까?

CPRule 이라는 클래스의 응집도는 높히대, 자신이 사용하지 않는 메소드를 분리해서 사용할 수 있게 된다.

이러한 부분은 BlockTransaction, EmailReporting 클래스가 직접 CPRule 에 접근하지 않아도 CPRule이 제공하는 서비스를 이용할 수 있게 된 것이다.

전형적인 ISP 를 보자

A, B, C 세 개의 클라이언트가 Service 인터페이스에 의존 관계를 맺고 있다.

만약에 Service 인터페이스의 어느 하나가 바귄다면, 세 클라이언트 모두를 재 컴파일, 재배포하는 아주 귀찮은 상황이 발생한다. 하지만 이를 ? 아래와 같이 변경한다면

기존에 발생했던 변화의 확산이 일어나지 않는다.

로버트 C.마틴은 "클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다." 라고 했다.

이 뿐만 아니라 ISP를 이야기할 때 항상 인터페이스를 통한 메서드를 외부에 제공할 때는 최소한의 메서드만 제공하라는 것이다. 명심할 필요가 있다.

단일 책임 원칙 (SRP)

SRP (Single Responsibility Principle ) 이란..?

직역하면 단일 책임 원칙이다. 사실 직관적인 단어라 어려운 부분이 없다고 생각했다. 하지만 예시를 확인해 봤을때 이게 뭔 말인가? 했다. 그래서 가지고 있던 책 중에 클린 코드를 확인 해보았다.

단일 책임 원칙은 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다.

아! 나는 기존에 정의된 하나의 클래스에 하나의 책임만을 가져야 된다는 것보다 이게 더 직관적으로 와닿았다.

Dashboard라는 클래스를 예시로 설명해보겠다.

public class Dashboard extends JFrame implements MetaData
{
    public Componet getLastFocusComp()
    public void setLastFocus(Component lastFocus)
    public int getMajorVersionNum()
    public int getMinorVersionNum()
    public int getBuildNum()
}

여기서 Dashboard의 역할은 두 개로 가정한다. 소프트웨어 버전 정보를 추적, Dashboard는 스윙 컴포넌트를 관리. 하지만 소프트웨어는 출시될때마다 버전 정보가 변경되며, 스윙 코드를 변경할 때마다 버전 번호가 달라진다. 자, 그럼 여기서 코드를 변경해야 하는 이유가 두 가지나 된다는 것이다.

따라서 이 코드에서 냄새를 제거해보자. 변경되는 이유를 찾았으니, 버전 정보를 다루는 메소드를 추출해서 새로운 클래스를 생성해보자. 여기서 버전 정보를 관리하는 메소드는 아래와 같다. 이를 Version 클래스로 만들어보자.

public class Version {
    public int getMajorVersionNum()
    public int getMinorVersionNum()
    public int getBuildNum()
}

이렇게 만들어진 Version 클래스는 다른 애플리케이션에서도 충분히 쉽게 사용될 것이다.

많은 주니어 개발자들은 깨끗하고 체계적인 소프트웨어보다 돌아가는 소프트웨어에 초점을 맞추는데, 사실 이건 비교하면 잘 정리된 여러 개의 수납장에 물건을 정리해서 사용할 것이냐? 큰 서랍장 하나에 모든 물건을 던져놓고 쓸 것이냐? 이다. 느껴지지 않는가? 냄새나는 코드의 제거는 중요하다.

마음의 정화를 가져오는 SRP, PEACE

객체 지향에 대해서 본격적인 공부를 시작하면서 보게 된 포스팅이 매우 인상 깊어 글을 작성하게 되었다.

아래는 원본글이니, 객체 지향을 공부하기 시작한 사람이라면 꼭 볼만한 포스팅이라 생각한다.

[객체지향 SW 설계의 원칙] ① 개방-폐쇄 원칙

개방-폐쇄 원칙

버틀란트 메이어는 개방-폐쇄 원칙을 다음과 같이 정의한다.

소프트웨어 구성 요소 ( 컴포넌트, 클래스, 모듈, 함수 ) 는 확장에 대해서는 개방되어야 하며, 변경에 대해서는 폐쇄되어야 한다. 이는 다시 말해 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 가능한 극대화해야 한다는 의미다.

이를 달성하기 위해서는 변경되는 부분, 변경되지 않는 부분을 엄격하게 구분해야 한다. 구분을 통해서 변하는 것은 가능한 변하게 쉽게하고, 변하지 않는 것은 변하는 것에 영향을 받지 않도록 하는 것이다. 그리고 인터페이스를 변하는 것과 변하지 않는 것의 중간 지점에서 서로를 보호하는 중재자 역할을 해야된다.

따라서, 이를 통해서 얻을 수 있는 것은 객체 간의 관계를 단순화해 복잡도를 줄이고, 확장이나 변경에 의해 발생하는 충격을 줄일수 있다.

혹시 복잡한가?

그럼 좀 더 쉽게 로버트 C.마틴의 말을 인용해보겠다. "소프트웨어 엔티티는 확장에 대해서는 열려 있어야하고 , 변경에 대해서는 닫혀있어야 된다." 라는 말을 쉽게 풀어보면 "나는 확장될 수 있어야하며, 다른 사람이 변하더라도 나에게 영향을 끼치면 안된다". 좀 더 이해가 됐으면 좋겠다.

자, 위 포스팅에서는 중재자의 역할, OCP의 인터페이스 기능으로 하는 예로 24핀 표준 규격의 충전기를 든다. 공통된 규격의 충전기는 사용자가 충전기를 사용함에 있어서 신뢰할 수 있고, 충전기 제공자는 목적에 맞게 확장, 특화하여 차별화나 상품성을 높일 수 있다. 물론 지금은 USB-C type이 표준이라 볼 수 있겠다.

하나의 예를 더 들어보자.

스프링 입문을 위한 자바 객체 지향의 원리와 이해에 들어있는 예제를 보겠다..

위 [그림 1]을 보게 되면 운전자는 기존에 마티즈를 타다가 새로운 자동차 소나타를 구매했다. 차량 종류를 변경하자 기본에 마티즈에서 수동으로 하던 일을 자동으로 변경되었다. 단순히 스틱 차량에서 오토 차량으로 변경되었다고 해서 기존의 운전자의 역할이 변화되어야 되는가? 현실 세계에서 봤을때는 어느 정도 Yes 라는 대답은 하겠지만, 객체 지향에서는 아니다. OCP에 위반되기 때문이다. 그럼 어떻게 해야하는가?

다소 위 예제가 억지스럽다고 느낄 수 있지만, 그려려니 해주셨으면 한다.

[그림 2]와 같이 기존의 공통된 특성을 추출하여 클래스나, 인터페이스를 생성하면 운전자 클래스는 다양한 자동차가 생긴다 하더라도 운전자 클래스에는 영향을 끼치게 않게 된다. 또한 자동차 입장에서는 확장에는 개방되어 있다.

개방 폐쇄 원칙에 대해서 이 글을 보며 조금이라도 이해했다면? 대표적인 개방 폐쇄 원칙을 지킨 가장 큰 예제는 JDBC이다.

JDBC를 사용하는 클라이언트는 데이터베이스가 오라클, MySQL, MariaDB 어떤 데이터베이스를 사용하더라도 Connection을 설정하는 부분을 제외하고는 모두 동일하게 사용 가능하다.

자신의 코드는 수정할 필요가 없이 변화에 대해서는 닫혀있으며, 다양한 데이터베이스 연결에 대해서는 확장에 열려있다고

볼 수 있다. 이러한 개방 폐쇄 원칙을 잘 지킴으로써 완충 역할을 하고 있는 것이다.

OCP 주의점

여기서 3가지 주의점에 대해서 언급한다. 아직 주니어 개발자라 격하게 공감하지 못하지만 명언처럼 마음에 담아두게 되었다.

1. 공통 모듈 설계

   • 공통된 루틴이나 변수를 리팩토링하여 분리를 하게 되었을 때, 공통 모듈이 작을 경우 공통 모듈 재사용을 얻기 위해 너무 잦은 모듈을 접근해야 하고 모듈 구성도를 지저분하게 할 경향이 높다. 설계자의 좋은 자질 중 하나는 OCP에서 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절을 잘 할 수 있는 결단력이라는 것이다.

2. 확장을 보장하는 Open 모듈에서 인터페이스의 변경인가, 어댑터 사용인가

   • 확장을 보장하는 open 모듈 영역에서 예측하지 못한 확장 타입을 만났을 때 인터페이스 변경하려는 안과 어댑터를 사용하려는 안 사이에서 갈등하게 된다. 위의 두 예에서처럼 변경의 충격이 적은 후자를 택하는 경우가 대부분이다. 한 번 정해진 인터페이스는 시간이 갈수록 사용하는 모듈이 많아지기 때문에 바꾸는데 엄청난 출혈을 각오해야 한다. 그 대표적인 예가 자바의 deprecated API라 한다.

     인터페이스는 가능하면 변경하면 안 되며, 이를 달성하기 위해서는 여러 경우의 수에 대한 고려와 예측이 필요하다. 과도한 예측은 불필요한 작업을 만들기에, 설계자의 적절한 예측 능력이 필요하다.

3. 커맨드의 역할

   • 요청자와 처리자 사이의 계약을 커맨드라 지칭하고 있다. 여기서 처리자는 execute()란 인터페이스만 알면 어떠너 처리도 수행할 수 있다. 따라서 서로 의미적 관계가 없는 Command들도 execute()란 메소드로 무엇이든 확장할 수 있다. OCP 구조에서 서버가 확장할 수 있는 운신의 폭이 넓어진 반면 클라이언트는 서버가 어떤 처리를 하는지 무지해진다.

     즉, 인터페이스 설계에서 적당한 추상화 레벨을 선택하는 것이 중요하다. 추상화라는 개념에 '구체적이지 않은' 정도의 의미로 약간 느슨한 개념을 갖고 있다.

     그래디 부치가 말하는 추상화는 '추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징' 이라고 한다. 따라서 이 '행위'에 대한 본질적인 정의를 통해 인터페이스를 식별해야 한다.

     포스팅에서 유일하게 이해되지 않는 부분은 '행위' 라는 부분이다. 혹여라도 지나가시던 객체 지향 고수분이 있으시다면 댓글을 큰 해소점이 될 것 같다.