'디자인패턴'에 해당되는 글 2건

안녕하세요 오늘의 5분개발지식라디오~ 오늘의 주제는 팩토리 패턴입니다. 팩토리 메소드 패턴이라고도 하는데요, 팩토리 패턴이 무엇인지 코드를 통해서 먼저 알아보고 팩토리 패턴의 장단점에 대해서 알아보겠습니다.

화면에 보이는 것은 자바로 쓰여진 코드인데요, 상속에 대한 개념만 있다면 쉽게 이해할 수 있습니다. 먼저 부모 클래스인 Shape 클래스를 통해서 인터페이스를 정의해줍니다. Shape의 자식 클래스들은 draw라는 메소드를 구현해야하는데요,

Reactangle, Square, Circle 모두 부모클래스인 Shape를 상속받고 각자 draw를 구현합니다. 단순하게 출력만 해주도록 하였습니다. 여기서 모두 같은 부모클래스를 가지고 있다는 점을 기억해주시면 됩니다.

팩토리 패턴의 핵심은 현재 화면에 보여지는 코드인데요, 이름부터가 ShapeFactory입니다. ShapeFactory는 getShape라는 메소드를 가지고 있으며 Shape 클래스를 리턴해줍니다. 이는 앞의 슬라이드에서 모두 같은 부모클래스인 Shape을 가지기 때문에 가능합니다.

getShape 메소드는 인자로 넘어오는 shapeType에 따라서 Circle, Rectangle, Sqare를 생성하여 반환하여줍니다. 이렇듯 팩토리 패턴은 팩토리 메소드를 통해서 인자로 넘어온 값에 따라 맞는 클래스를 생성하여 주는 패턴을 말합니다.

먼저 장점을 알아보겠습니다.

첫번째로 확장성이 좋습니다. 새로운 타입의 추가가 쉽습니다. 동일한 부모 클래스를 상속하는 클래스를 생성하고 팩토리 메소드에 분기를 하나만 추가하면 됩니다. 이는 SOLID 원칙의 Open-closed 원칙을 따른다고 볼 수 있습니다.

두번째로 테스트가 용이합니다. 팩토리 메소드가 따로 분리되어있기때무에 이 부분을 직접적으로 테스트 가능하고, 필요하다면 자식클래스들도 따로 테스트 할 수 있습니다.

다음은 단점입니다.

첫번째로 코드양이 증가합니다. 결과론적으로 팩토리 클래스를 선언해야되기때문에 근소하지만 추가적인 공수가 발생합니다.

다음은 팩토리메소드의 단점이라고 보기는 어렵지만 실제 동작코드가 팩토리 메소드에 한번 추상화되어있기때문에 전체적인 코드를 파악하기에 조금 더 힘들 수 있습니다.

끝

안녕하세요~ 오늘은 Facade pattern에 대해서 이야기해보려고 합니다.

> 어원

Facade pattern은 소프트웨어 디자인 패턴 중 하나인데요, 주로 객체지향 프로그래밍에서 많이 쓰입니다. ‘파사드’라는 단어를 사전에 검색해보면 “건물의 정면”이라는 뜻으로 나옵니다. 여기서 추측할 수 있듯이 어떠한 코드의 정면, 껍데기 역할을 하는 오브젝트를 두는 패턴을 뜻합니다.

> 설명

어떻게 생각하면 추가적인 레이어를 하나 더 두는 것인데요, 이렇게 하는 이유는 주로 복잡한 코드를 감추기 위해서입니다. 일종의 추상화와 비슷하다고 생각하시면 됩니다. 복잡한 내부로직을 그대로 노출시켜서 사용하게하면 복잡하니, 좀 더 쉽게 셀계된 인터페이스인 파사드 객체를 노출시키는 것입니다. 이 파사드 객체가 내부로직을 호출하게 되구요.

> 사용처

파사드 패턴은 주로 다음과 같은 경우에 사용됩니다.

• 첫번째, 간단한 인터페이스를 통해 복잡한 시스템을 접근하도록 하고 싶을때
• 두번째, 시스템이 너무 복잡할때

어떻게 보면 첫번째와 연결된 이유이죠?

• 세번째, 시스템을 사용하고 있는 외부와 결합도가 너무 높을때 의존성을 낮추기 위해서

> 장점

파사드 패턴을 적용하면 가장 큰 장점이 2가지가 있습니다.

• 첫번째, 외부에서 사용하기가 쉽습니다.

파사드 패턴을 적용하는 가장 근본적인 이유이지만, 추가적인 레이어를 파사드 객체를 통해 제공하여 외부에서 사용하기 쉽도록 인터페이스를 간소화하여 노출시키기 때분에 복잡한 기존의 내부로직을 사용하지 않습니다.

• 둘째, 의존성이 감소합니다

이전에는 외부에서 내부 로직을 직접 사용하기 때문에 내부 로직의 구조를 변경한다거나, 파라미터나 리턴값을 변경할 경우 직접적으로 영향을 받아 수정이 힘들거나 불가능한 경우가 종종 있습니다. 하지만 중간에 매개체 역할을 해주는 파사드 객체가 있기때문에 실제 내부 로직은 어떻게 변경이 되더라도 상관이 없어지므로 의존성이 감소합니다.

> 사용예시

마지막으로 위키피디아에 올라와있는 예시까지만 살펴보겠습니다.

c++로 작성된 코드인데요, 상단의 CPU, HardDrive, Memory쪽을 지금까지 이야기하던 복잡한 내부로직이라고 생각하시면됩니다. 만약 다음과 같은 코드를 라이브러리로 제공하여 외부에서 사용할 수 있도록 한다고 생각해보면, CPU, HardDrive, Memory 3개의 클래스를 제공해주고 사용처에서 알아서 적절히 섞어서 사용하도록 해도됩니다.

하지만 이 경우, 사용처에서 각각의 부품들이 제공하는 메소드들이 어떤 역할을 하는지 파악해야하고, 실행되는 순서또한 매우 중요합니다. 그렇기때문에 파사드객체인 ComputerFacade를 통해서 사용하도록 하는 것입니다. 사용처에서는 복잡하게 컴퓨터 내부 부품들의 메소드들을 알 필요없이 ComputerFacade객체의 start 메소드만 호출하면되는 것입니다.

정리하자면, 다음 예시와 같이 파사드 객체를 제공하면 사용처에서 복잡하게 내부 로직들을 알필요없이 사용하기 쉽도록 추상화된 파사드 객체를 사용하면 되기때문에 훨씬 사용하기 용이해집니다. 또, 이것을 제공하는 측에서는 사용자가 직접 내부로직을 사용하지 않기때문에 CPU, HardDrive, Memory와 같은 내부로직을 수정, 추가, 삭제하는 것이 훨씬 자유로워지는 의존성 감소 효과 또한 받을 수 있게됩니다. 

하지만 반대로 어찌되었건 추가적인 코드가 늘어나는 것이기 때문에 유지보수 측면에서 공수가 더 많이드는 것은 사실이므로 추상화하고자하는 시스템이 얼마나 복잡한지, 파사드 패턴을 통해서 얻게되는 이점이 추가적인 유지보수 비용보다 클지를 잘 따져보고 적용해야될 것 같습니다.

끝!