Schuna Blog Post

템플릿 메소드와 스트레티지 패턴

2022-04-01T11:27:28+00:00

Template Method와 Strategy Pattern은 비슷한 문제를 해결하고, 보통 호환되어 쓰인다. 그러나 , 탬플릿 메소드는 문제를 해결하기 위해 상속을 사용하는 반면, 스트레티지는 위임을 사용한다. 탬플릿 메소드와 스트레티지는 둘 다 구체적인 내용으로부터 일반적인 알고리즘을 분리하는 문제를 해결하는 패턴이다. 의존 관계 역전을 따르기 위해서는 이 일반적인 알고리즘이 구체적 구현에 의존하지 않도록 해야 하며, 일반적인 알고리즘과 구체적인 구현이 추상화에 의존하게 해야한다.

탬플릿 메소드 패턴

기본적인 메인 루프 구조

initialize();

while(!done())
{
    Idle();
}

cleanUp();

먼저, 어플리케이션을 초기화 한다. 그리고 메인 루프에 들어 간다. 메인 루프에서 프로그램이 요구하는 어떤 일을 한다. 예를 들어 GUI 이벤트를 처리하거나, 데이터 베이스 레코드를 처리할 수도 있을 것이다. 마지막으로, 모든 일이 끝나면 메인 루프를 나가면서 정리를 한다.

이 구조는 아주 평범하므로 Application이라는 이름의 클래스에 집어 넣는다. 그러고 나면 작성하려는 모든 새 프로그램에서 이 클래스를 재사용할 수 있다.

화씨 온도를 섭씨 온도로 변환하는 프로그램(초기 버전)

def main():
    done = False

    while not done:
        print("Input Fahrenheit:")
        fahrenheit = number_from_input_stream()
        if fahrenheit is None:
            done = True
        else:
            celsius = 5.0 / 9.0 * (fahrenheit - 32)
            print(f"{fahrenheit:.2f}℉ = {celsius:.2f}℃")

    print("Fahrenheit to Celsius Finished!")
		
def is_number(s):
    try:
        float(s)
        return True
    except ValueError:
        return False

def number_from_input_stream():
    parsed_number = [float(s) for s in sys.stdin.readline().split() if is_number(s)]
    if len(parsed_number) == 1:
        return parsed_number[0]
    else:
        return None
	

Application 추상 클래스

class Application(metaclass=ABCMeta):
    def __init__(self):
        self.done = False

    @abstractmethod
    def init(self):
        raise NotImplementedError  # pragma: no cover

    @abstractmethod
    def idle(self):
        raise NotImplementedError

    @abstractmethod
    def cleanup(self):
        raise NotImplementedError

    def set_done(self):
        self.done = True

    def run(self):
        self.init()
        while not self.done:
            self.idle()
        self.cleanup()

이 클래스는 일반적인 메인 루프 애플리케이션을 묘사하고 있다. 구현된 run 함수에서 메인 루프를 볼 수 있다. 모든 구체적인 작업이 추상 메소드인 init, idle, cleanup에 맡겨진 것 또한 볼 수 있다. Application 을 상속하여 구현한 결과는 아래와 같다.

class TemperatureConverter(Application):
    def __init__(self):
        super().__init__()

    def init(self):
        self.done = False

    def idle(self):
        print("Input Fahrenheit:")
        fahrenheit = number_from_input_stream()
        if fahrenheit is None:
            self.set_done()
        else:
            celsius = 5.0 / 9.0 * (fahrenheit - 32)
            print(f"{fahrenheit:.2f}℉ = {celsius:.2f}℃")

    def cleanup(self):
        print("Fahrenheit to Celsius Finished!")


if __name__ == '__main__':
    converter = TemperatureConverter()
    converter.run()

이렇게 특정 애플리케이션에 탬플릿 메소드를 사용하는 것은 바람직하지 않다. 프로그램이 복잡해지고 내용만 더 늘어날 뿐이다.

템플릿 메소드 패턴은 객체 지향 프로그래밍에서 고전적인 재사용 형태 중의 하나를 보여준다. 일반적인 알고리즘은 기반 클래스에 있고, 다른 구체적인 내용에서 상속된다. 상속은 아주 강한 관계여서, 파생 클래스는 필연적으로 기반 클래스에 묶이게 된다.

스트래티지 패턴

스트래티지 패턴은 일반적인 알고리즘과 구체적인 구현 사이의 의존성 반전 문제를 완전히 다른 방식으로 풀어낸다. 앞의 탬플릿 패턴과 같이 일반적인 알고리즘을 추상 기반 클래스에 넣는 대신, ApplicationRunner라는 이름의 구체 클래스에 넣는다. Application이란 이름의 인터페이스 안에서 일반적 알고리즘이 호출해야할 추상 메소드를 정의한다. 이 인터페이스에서 ConverterStrategy를 파생시켜 ApplicationRunner에게 넘겨 준다. 그러면 ApplicationRunner는 이 인터페이스에 위임한다.

ApplicationRunner Class

class ApplicationRunner:
    def __init__(self, application):
        self.application = application

    def run(self):
        self.application.init()
        while not self.application.done:
            self.application.idle()
        self.application.cleanup()

Application Interface

class Application(metaclass=ABCMeta):
    @abstractmethod
    def init(self):
        raise NotImplementedError

    @abstractmethod
    def idle(self):
        raise NotImplementedError

    @abstractmethod
    def cleanup(self):
        raise NotImplementedError

    @abstractmethod
    def set_done(self):
        raise NotImplementedError

ConverterStrategy Class

class ConverterStrategy(Application):
    def __init__(self):
        self.done = False

    def init(self):
        self.done = False

    def idle(self):
        print("Input Fahrenheit:")
        fahrenheit = number_from_input_stream()
        if fahrenheit is None:
            self.set_done()
        else:
            celsius = 5.0 / 9.0 * (fahrenheit - 32)
            print(f"{fahrenheit:.2f}℉ = {celsius:.2f}℃")

    def cleanup(self):
        print("Fahrenheit to Celsius Finished!")

    def set_done(self):
        self.done = True

main 함수

runner = ApplicationRunner(ConverterStrategy())
runner.run()

이 구조는 이익과 비용 면에서 템플릿 메소드 구조에 비해 더 낫다는 사실이 명백하다. 스트래티지에는 탬플릿 메소드보다 더 많은 전체 클래스 개수와 더 많은 간접 지정이 있다. ApplicationRunner 내부의 위임 포인트는 실행 시간과 데이터 공간 면에서 상속의 경우보다 좀 더 많은 비용을 초래한다. 반면, 서로 다른 많은 애플리케이션을 실행한다면, ApplicationRunner 인스턴트를 재사용하여 Application의 다른 많은 구현에 이것을 넘겨 줄 수 있을 테고, 그럼으로써 일반적인 알고리즘과 그성이 제어하는 구체적인 부분 사이의 결합 정도를 감소 시킬 수 있다.

템플릿 메소드 패턴이 일반적인 알고리즘으로 많은 구체적인 구현을 조작할 수 있게 해주는 반면, DIP를 준수하는 스트래티지 패턴은 각각의 구체적인 구현이 다른 많은 일반적인 알고리즘에 의해 조작될 수 있게 해준다.

Active Object Pattern

2022-03-31T20:17:31+00:00

ActiveObject 객체는 Command 객체의 리스트를 유지한다. 사용자는 ActiveObject에 새로운 명령을 추가할 수도 있고, run()을 호출할 수 도 있다. run()은 단순히 각 명령을 실행하고 제거하면서 리스트를 훑어 나가는 함수다.

ActiveObject

class ActiveObject:
    def __init__(self):
        self.command_queue = []

    def add_command(self, command):
        self.command_queue.append(command)

    def run(self):
        while len(self.command_queue):
            command = self.command_queue.pop(0)
            command.execute()						

Command Interface

class Command(metaclass=ABCMeta):
    @abstractmethod
    def execute(self):
        raise NotImplementedError				

이것은 그다지 특별해 보이지 않는다. 하지만 리스트에 있는 Command 객체 중 하나가 자기를 복제하여 그 복제본을 리스트에 다시 넣는다면 어떤 일이 일어날까? 이 리스트는 절대 비지 않게되고 run()함수는 절대로 return하지 않을 것이다.

SleepCommand

class SleepCommand(Command):
    def __init__(self, milliseconds, active_object, wakeup_command):
        self.start_time = 0
        self.sleep_time = milliseconds
        self.active_object = active_object
        self.wakeup_command = wakeup_command
        self.started = False

    def execute(self):
        current_time = current_time_milliseconds()
        if not self.started:
            self.started = True
            self.start_time = current_time
            self.active_object.add_command(self)
        elif (current_time - self.start_time) < self.sleep_time:
            self.active_object.add_command(self)
        else:
            self.active_object.add_command(self.wakeup_command)

WakeupCommand

class WakeupCommand(Command):
    def execute(self):
        print("Command Executed!")

TestSleepCommand

SleepCommand의 생성자는 3개의 인자를 갖는다. 첫 번째는 ms 단위의 지연 시간이다. 두 번째는 이 명령이 실행될 장소인 ActiveObject이다. 마지막 인자는 wakeup이라는 또 다른 명령 객체이다. 이 테스트가 기대하는 동작은 SleepCommand가 일정 시간만큼 기다렸다가 wakeup 명령을 실행하는 것이다.

class TestSleepCommand(TestCase):
    def setUp(self) -> None:
        self.active_object = ActiveObject()
        self.sleep_command = SleepCommand(1000, self.active_object, WakeupCommand())
        self.active_object.add_command(self.sleep_command)

    def test_execute(self):
        expected = "Command Executed!\n"
        buf = io.StringIO()

        start_time = current_time_milliseconds()
        with contextlib.redirect_stdout(buf):
            self.active_object.run()
        sleep_time = current_time_milliseconds() - start_time

        self.assertTrue(sleep_time >= 1000)
        self.assertTrue(sleep_time < 1100)
        self.assertEqual(expected, buf.getvalue())

이 기법의 다양한 변형을 사용하여 멀티스레드 시스템을 구축하는 것은, 지금까지도 그래왔고 앞으로도 계속될 아주 일반적인 실천 방법이다. 이런 종류의 스레드는 각 Command 인스턴트가 다음 Command 인스턴트 실행이 가능해지기 전에 완료되기 때문에, RTC(run-to-completion) 테스크라는 이름으로 알려져 있다. Command인스턴트가 모두 완료될 때까지 실행된다는 사실은 RTC 스레드에 모두 같은 런타임 스택을 공유한다는 흥미로운 이점을 부여한다. 전통적인 멀티스레드 시스템에서의 스레드와 달리 여기서는 각 RTC 스레드에 대해 별도의 런타임 스택을 정의하거나 할당할 필요가 없다. 이것은 많은 스레드가 실행되고 메모리가 제한된 시스템에서 강력한 이점이 될 수 있다.

Command Pattern

2022-03-31T19:28:42+00:00

단순한 커맨드 적용

복사기 소프트웨어를 위한 단순한 커맨드 패턴

이 구조를 제대로 만들면 Command 객체를 시스템에 차례로 넘겨 줄 수 있고, 그것이 정확히 어떤 종류의 Command를 표현하는지 알 필요 없이 do()를 실행할 수 있다. 이 것은 흥미로운 단순화로 이어진다. 이 시스템은 이벤트 주도적이다. 시스템에서 일어나는 특정 이벤트에 따라 릴레이가 열리거나 닫히고, 모터는 움직이거나 멈추고, 클러치는 접속되거나 차단된다. 이 이벤트 대부분은 센서에 의해 탐지된다. 예를 들어, 종이 한 장이 용지 통로의 일정한 위치에 이르렀음을 광센서가 감지하면 특정 클러치를 접속시켜야 한다. 이를 위해 그냥 해당하는 ClutchOnCommand를 그 광센서를 제어하는 객체와 묶어 구현하면 된다.

센서는 자신이 하는 일을 모른다. 그저 어떤 이벤트를 탐자할 때마다 묶여 있는 Command에서 do()를 호출할 뿐이다. Sensor가 개별적인 클러치나 릴레이에 대해 알 필요가 없다는 뜻이다. 따라서 Sensor의 함수는 단순해질 수 있다.

Command Pattern은 명령의 개념을 캡슐화함으로써 연결된 장치에서 시스템의 논리적인 상호 연결을 분리해 낼 수 있게 한다.

트랜젝션

커맨드 패턴의 또 다른 일반적인 사용법이자 급여 관리 문제에서 유용하게 쓸 수 있는 방법은 트랜젝션의 생성과 실행에 관련되어 있다. 예를 들어 직원들의 데이터 베이스를 관리하는 시스템을 작성하고 있다고 생각해 보자. 사용자들은 이 데이터 베이스를 이용하여 새 직원을 추가하고 기존 직원을 삭제하고 직원의 속성을 변경하는 등의 작업을 할 수 있다.

Command 객체는 검증되지 않은 데이터를 위한 저장소 역할을 하고, 검증 메소드를 구현하여, 마지막으로 트랜젝션을 실행하는 메소드를 구현한다. AddEmployeeTransaction은 Employee가 포함하고 있는 것과 똑같은 데이터 필드를 갖고 있다. 또한 PayClassification객체에 대한 포인터도 저장한다. 이 필드와 객체는 시스템에 새로운 직원을 추가하려는 지시가 있을 때, 사용자가 지정한 날짜에 의해 생성된다.

물리적 분리

사용자에게서 데이터를 받는 코드와 그 데이터를 검증하고 그것으로 작업을 하는 코드, 그리고 업무 객체 그 자체를 극적으로 분리한다.

시간적 분리

검증과 실행 코드를 분리할 수 있다. 이 트랜젝션 객체는 우선 목록에 저장되어 검증되고나서 나중에 실행될 수 있다.

Weather Station 설계 (옵저버 패턴)

2022-03-27T19:21:00+00:00

기상 스테이션 설계

클래스 다이어 그램

기상 스테이션 구현

public interface Subject {
 public void registerObserver(Observer o);
 public void removeObserver(Observer o);
 public void notifyObserver(Observer o);
}

public interface Observer {
 public void update(float temp, float humidity, float pressure);
}

public interface DisplayElement {
 public void display();
}

상태를 갱신하기 위해 측정치를 직접 전달하는 것이 좋은 방법일까? 갱신된 상태를 옵저버에 전달하는 다른 좋은 방법을 고려해 보자.

WeatherData에서 Subject Interface 구현하기

public class WeatherData implements Subject {
 private ArrayList observers;
 private float temperature;
 private float humidity;
 private float pressure;
 
 public WeatherData() {
  observers = new ArrayList();
 }
	
public void registerObserver(Observer o) {
 observers.add(o);
}
		
public void removeObserver(Observer o) {
 int i = observers.indexOf(o);
 if(i >= 0) {
  observers.remove(i);
 }
}
		
public void notifyObservers() {
 for(int i = 0; i < observers.size(); i++) {
  Observer observer = (Observer)observers.get(i);
	observer.update(temperature, humidity, pressure);
 }
}

 public void measurementChanged() {
  notifyObservers();
 }
		
public void setMeasurements(float temperature, float humidity, float pressure) {
 this.temperature = temperature;
 this.humidity = humidity;
 this.pressure = pressure;
 }
	// 기타 WeatherData method
}

Display 항목 구현하기

public class CurrentConditionDisplay implements Observer, DisplayElement {
	private float temperature;
	private float humidity;
	private float pressure;
		
	public CurrentCoditionDisplay (Subject weatherData) {
		this.weatherData = weatherData;
		weatherData.registerObserver(this);
	}
		
	public void update(float temperature, float humidity, float pressure) {
		this.temperature = temperature;
		this.humidity = humidity;
		display();
	}
		
	public void display() {
		System.out.println("Current coditions: " + temperature + "F degrees and " + humidity + "% humidity");
	}
}

기상 스테이션 실행

public class WeathreStation {
 public static void main(String[] args) {
  WeatherData weatherData = new WeatherData();
	CurrentConditionDisplay currentDisplay = new CurrentConditionDisplay(weatherData);				
	StatisticsDisplay statisticsDisplay = new StatisticsDisply(weatherData);
	ForecastDisplay forecastDisplay = new ForecastDisplay(weatherData);
	
	weatherData.setMeasurements(80, 65, 30.4f);
	weatherData.setMeasurements(82, 70, 29.2f);
	weatherData.setMeasurements(78, 90, 29.2f);
 }
}

Observer Pattern의 정의

2022-03-27T18:14:08+00:00

정의

옵저버 패턴에서는 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의합니다.

클래스 다이어그램

[그림1 ]

옵저버 패턴에서 상태를 저장하고 지배하는 것은 주제 객체 입니다.
따라서 상태가 들어 있는 객체는 하나만 있을 수 있습니다.
옵저버는 여러 개가 있을 수 있으며, 주제 객체에서 상태가 바뀌었다는 것을 알려 주기를 기다리는, 주제에 의존적인 성질을 가지게 된다.
그러므로 하나의 주제와 여러 개의 옵저버가 연과된, 일대다 관계가 성립한다.
데이터 주인은 주제입니다.
옵저버는 데이터가 변경되었을 때 주제에서 갱신해 주기를 기다리는 입장이기 때문에 의존성을 가진다고 할 수 있습니다.
이런 방법을 사용하면 여러 객체에서 동일한 데이터를 제어하도록 하는 것에 비해 더 깔끔한 객체지향 디자인을 만들 수 있습니다.

느슨한 결합의 위력

두 객체가 느슨하게 결합되어 있다는 것은, 그 둘이 상호작용을 하긴 하지만 서로에 대해 잘 모른다는 것을 의미합니다.
옵저버 패턴에서는 주제와 옵저버가 느슨하게 결합되어 있는 객체 디자인을 제공합니다.

주제가 옵저버에 대해서 아는 것은 옵저버가 특정 인터페이스를 구현한다는 것 뿐입니다.

옵저버의 Concrete Class가 무엇인지, 옵저버가 무엇을 하는지 등에 대해서는 알 필요가 없습니다.

옵저버는 언제든지 새로 추가할 수 있습니다.

주제는 옵저버 인터페이스를 구현하는 객체의 목록에만 의존하기 때문에 언제든지 새로운 옵저버를 추가할 수 있다. 실행 중에 한 옵저버를 다른 옵저버로 바뀌도 되고, 그렇게 해도 주제 객체는 계속해서 데이터를 보낼 수 있다. 마찬가지로 옵저버를 아무 때나 제거해도 된다.

새로운 형식의 옵저버를 추가하려고 할 때도 주제를 전혀 변경할 필요가 없다.

옵저버가 되어야 하는 새로운 구상 클래스가 생겼다고 가정해 보자. 이 때도 새로운 클래스 형식을 받아 들일 수 있도록 주제를 바꿔야 할 필요는 없다. 새로운 클래스에서 Observer 인터페이스를 구현하고 옵저버로 등록하기만 하면 된다. 주제 객체는 전혀 신경도 쓰지 않는다.

주제와 옵저버는 서로 독립적으로 재 사용할 수 있다.

주제나 옵저버를 다른 용도로 활용할 일이 있다고 해도 손쉽게 재 사용할 수 있다. 그 둘이 서로 단단하게 결합되어 있지 않기 때문이다.

주제나 옵저버가 바뀌더라도 서로한테 영향을 미치지 않는다.

둘이 서로 느슨하게 결합되어 있기 때문에 주제 혹은 옵저버 인터페이스를 구현한다는 조건만 만족 된다면 어떻게 바꿔도 문제가 되지 않는다.

디자인 원칙

서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.

SimDuck 예제

2022-03-26T14:50:55+00:00

SimDuck 응용 프로그램 시작


그림1

오리들이 날아 다닐 수 있도록 변경


그림2

그런데 심각한 문제가 생겼습니다.


그림3

Duck 수퍼 클래스에 fly가 추가 되면서 모든 서브 클래스들이 날 수 있게 되는 문제가 발생

프로그램 한 부분의 변경으로 프로그램 전체에 부작용이 발생(날아 다니는 고무 오리)

상속에 대해 생각해 봅시다 소리를 내지 않거나 날 수 없을 경우 quack과 fly 메소드를 override하면 될까? Duck의 행동을 제공하는 데 있어 상속을 사용할 경우 아래와 같은 단점이 발생 한다
- 서브 클래스에서 코드가 중복 된다.
  - 실행시 특징을 바꾸기 어렵다
  - 모든 오리의 행동을 알기 어렵다.
  - 코드를 변경 했을 때 다른 오리들 한테 원치 않는 영향을 끼칠 수 있다.


그림4

인터페이스는 어떨까?


그림5

모든 서브 클래스에 날거나 꽥꽥거리는 기능이 있어야 하는 것은 아니므로 상속을 사용하는 것이 올바른 해결책이 아니라는 것은 알 수 있다.
서브 클래스에서 Flyable, Quackable을 구현하도록 함으로써 일부 문제점은 해결할 수 있지만, 그렇게 하면 그러한 행동에 대한 코드 재사용을 전혀 기대할 수 없기 때문에 코드 관리 면에서 문제점을 야기한다.
날아가는 동작을 조금 변경하기 위해 날아 다닐 수 있는 서브 클래스 전체를 고쳐야 할 수 있다.

문제를 명확하게 파악하기

디자인 원칙

애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로 부터 분리 시킨다. 바뀌는 부분은 따로 뽑아서 캡슐화 시킨다. 그렇게 하면 나중에 바뀌지 않는 부분에는 영향을 주지 않은 채로 그 부분만 고치거나 확장할 수 있다.

바뀌는 부분과 그렇지 않은 부분 분리하기
fly()와 quack()은 Duck 클래스에서 오리 마다 달라지는 부분입니다.
이러한 행동을 Duck 클래스에서 분리하여 각각의 행동을 나타내는 클래스 집합을 만듭니다.
오리의 행동 디자인

디자인 원칙

구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.

각 행동은 인터페이스로 표현하고 행동을 구현할 때 이런 인터페이스를 구현하도록 한다.

인터페이스에 맞춰서 프로그래밍한다는 것은 사실 상위 형식에 맞춰서 프로그램밍한다는 것을 뜻합니다.

Duck의 행동을 구현하는 방법

FlyBehavior와 QuackBehavior라는 두 인터페이스를 사용합니다.


그림6

Duck 행동 통합하기

가장 중요한 점은 나는 행동과 꽥꽥 소리를 내는 행동을 Duck 클래스에서 정의한 메소드를 써서 구현하지 않고 다른 클래스에 위임한다는 것이다.


그림7

“A는 B이다” 보다 “A에는 B가 있다”가 나을 수 있다.

디자인 원칙

상속 보다는 구성을 활용 한다.

“A에는 B가 있다” 관계에 대해 생각해 봅시다.
각 오리에는 FlyBehavior와 QuackBehavior가 있으며, 나는 행동과 꽥꽥 거리는 행동을 위임 받습니다.
두 클새스를 이런 식으로 합치는 것을 구성을 이용하는 것이라고 부릅니다.
오리 클래스에서는 행동을 상속 받는 대신, 올바른 행동 객체로 구성됨으로써 행동을 부여 받게 됩니다.
이 테크닉은 매우 중요한 테크닉입니다.
구성을 이용하여 시스템을 만들면 유연성을 크게 향상시킬 수 있습니다.
단순히 알고리즘군을 별도의 클래스의 집합으로 캡슐화할 수 있도록 만들어 주는 것 뿐 아니라
구성요소로 사용하는 객체에서 올바른 행동 인터페이스를 구현하기만 하면 실행시에 행동을 바꿀 수도 있게 해 줍니다.

스트레티지 패턴

알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다.
스크래티지를 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

개방 폐쇄 원칙 (OCP)

2022-03-19T12:21:00+00:00

소프트웨어 개체(클래스, 모듈, 함수)는 확장에 열려 있어야하고, 수정에 닫혀 있어야 한다.

OCP가 잘 적용된다면, 이미 제대로 동작하는 원래 코드를 변경하는 것이 아니라 새로운 코드를 덧붙임으로써 나중에 그런 변경을 할 수 있게 된다.

해결책은 추상화다

모듈은 추상화를 조작할 수 있다. 이런 모듈은 고정된 추상화에 의존하기 때문에 수정에 대해 닫혀 있을 수 있다. 그 모듈의 행위는 추상화의 새 파생 클래스들을 만듦으로써 확장이 가능하다.

OCP를 따르지 않는 예제


그림1

OCP를 따르는 예제


그림2. 스트레티지 패턴, Client는 개방 폐쇄 원칙을 따른다

AbstractServer가 아닌 ClientInterface로 이름을 지은 이유:
추상 클래스는 자신을 구현하는 클래스 보다도 클라이언트에 더 밀접하게 관련되어 있기 때문이다.


그림3. 탬플릿 메소드 패턴, 기반 크래스는 개방 폐쇄 원칙을 따른다

그림3은 대안이 되는 구조를 보여 준다. Policy 클래스는 어떤 종류의 정책을 구현하는 구체적인 공용 함수들을 갖는데, 그림2에서 본 client의 함수 들과 비슷한 것이다. 이 정책 함수들은 어떤 추상 인터페이스의 형식을 통해 작업하려는 일을 설명한다. 그러나 이번에는 추상 인터페이스가 Policy클래스 자체의 한 부분이다. 자바의 경우 추상 메소드일 것이다. 이런 함수들은 Policy 서브 타입에서 구현된다. 따라서 Policy 내부에 명시된 행위는 Policy클래스의 새로운 파생클래스를 생성함으로써 확장되거나 수정될 수 있다.

단일 책임 원칙 (SRP)

2022-03-19T12:09:30+00:00

한 클래스는 단 한 가지의 변경 이유만을 가져야 한다.

SRP 위배 예제

그림1의 설계를 보자. 각기 다른 두 어플리케이션이 Rectangle 클래스를 사용한다. 하나는 계산 기하학을 위한 어플리케이션으로, Rectangle을 사용하여 기하학 도형의 수학적 계산을 돕지만 화면에 사각형을 그리지는 않는다. 다른 하나는 본질적으로 그래픽을 위한 어플리케이션이다. 이 어플리케이션도 계산 기하학 과련 동작을 조금 하긴 하지만, 화면에 직사각형을 그리는 것이 주된 기능이다. 따라서 이 설계는 Rectangle 클래스가 두 가지 책임을 지고 있으므로 단일 책임 원칙을 위반한다.


그림1

SRP 준수 예제

좀 더 나은 설계는 그림2와 같이 2개의 완전히 다른 클래스로 분리해 넣는 것이다.


그림2

Factory

2021-11-06T06:38:59+00:00

The aim of a creational design pattern is to provide better alternatives for situations where a direct object creation (which in Python happens by the init() function [j.mp/divefunc], [Lott14, page 26]) is not convenient.

In the Factory design pattern, a client asks for an object without knowing where the object is coming from(that is, which class is used to generate it).

class Point3:
    def __init__(self, x, y):
        self.x = x
        self.y = y 

    def __str__(self):
        return f"x: {self.x}, y: {self.y}"

    class PointFactory:
        @staticmethod
        def new_cartesian_point(x, y):
            return Point3(x, y) 
        @staticmethod
        def new_polar_point(rho, theta):
            return Point3(rho * cos(theta), rho * sin(theta))

    factory = PointFactory()

code

SRP

2021-11-03T06:09:30+00:00

Single Responsibility Principle

Class Should have its primary responsibility and should not take on other responsibilities.

Anti Pattern 예제

class Journal:
    def __init__(self):
        self.entries = []
        self.count = 0
    def add_entry(self, text):
        self.entries.append(f"{self.count}: {text}")
        self.count += 1
    def remove_entry(self, pos):
        del self.entries[pos]
    def __str__(self):
        return "\n".join(self.entries)
    # break SRP
    def save(self, filename):
        file = open(filename, "w")
        file.write(str(self))
        file.close()
    def load(self, filename):
        pass
    def load_from_web(self, uri):
        pass

개선하기 위해 아래 save, load 를 PersistenceManager Class로 구현

class PersistenceManager:
    def save_to_file(journal, filename):
        file = open(filename, "w")
        file.write(str(journal))
        file.close()

j = Journal()
j.add_entry("I cried today.")
j.add_entry("I ate a bug.")
print(f"Journal entries:\n{j}\n")
p = PersistenceManager()
file = r'c:\temp\journal.txt'
p.save_to_file(j, file)
# verify!
with open(file) as fh:
    print(fh.read())

pytest for Map Reduce

2021-10-31T13:14:04+00:00

conftest.py

…

@pytest.fixture
def tmp_dir():
    root_path = os.getcwd()
    letters = string.ascii_lowercase
    tmp_name = "".join(choice(letters) for _ in range(8))
    return os.path.join(root_path, tmp_name)

@pytest.fixture
def make_test_files(tmp_dir):
    print(f"\ntest_files at {tmp_dir}")
    os.makedirs(tmp_dir, exist_ok=True)
    letters = string.ascii_lowercase
    total_count = 0
    for i in range(10):
        with open(os.path.join(tmp_dir, "{:02d}.txt".format(i)), "w") as wf:
            for j in range(randint(100, 200)):
                line: str = "".join(choice(letters) for k in range(160)) + "\n"
                total_count += 1
                wf.write(line)
    return total_count

@pytest.fixture
def test_files_ready(request, make_test_files, tmp_dir):
    total_count = make_test_files
    def teardown_remove_temp():
        print(f"\nremove {tmp_dir}")
        remove_dir(tmp_dir)
    request.addfinalizer(teardown_remove_temp)
    return total_count

@pytest.fixture
def elapsed_time():
    start = datetime.now()
    yield
    elapsed = datetime.now() - start
    print(f"\nruntime={elapsed.total_seconds():.3f}sec")

test for input data

import pytest
import os
from src.mapreduce import InputData
from src.mapreduce import FileInputData

def test_input_data_read_not_implemented_error():
    input_data = InputData()
    with pytest.raises(NotImplementedError):
        input_data.read()

def test_input_data_generate_inputs_not_implemented_error():
    input_data = InputData()
    with pytest.raises(NotImplementedError):
        input_data.generate_inputs("path")
@pytest.mark.usefixtures("test_files_ready")

def test_create_file_input_data_ok(tmp_dir):
    file_path = os.path.join(tmp_dir, "00.txt")
    file_input_data = FileInputData(file_path)
    assert file_input_data.path == file_path
@pytest.mark.parametrize("data_dir", ["", "file.txt"])

def test_create_file_input_data_ng(data_dir):
    with pytest.raises(ValueError):
        FileInputData(data_dir)

test for Map Reduce

import pytest
from src.mapreduce import map_reduce
from src.mapreduce import FileInputData
from src.mapreduce import LineCountWorker

def test_map_reduce_performance(elapsed_time, test_files_ready, tmp_dir):
    total_count = test_files_ready
    result = map_reduce(LineCountWorker, FileInputData, tmp_dir)
    assert result == total_count

Map Reduce

2021-10-31T12:56:25+00:00

Input Class 선언

class InputData(object):
    def read(self):
        raise NotImplementedError

    @classmethod
    def generate_inputs(cls, file_path: str):
        raise NotImplementedError


class FileInputData(InputData):
    def __init__(self, file_path):
        if not file_path:
            raise ValueError(f"path error : {file_path}")
        super().__init__()

        if not os.path.isfile(file_path):
            raise ValueError(f"file not exists {file_path}")

        self.path = file_path

    def read(self):
        return open(self.path).read()

    @classmethod
    def generate_inputs(cls, path: str):
        for name in os.listdir(path):
            yield cls(os.path.join(path, name))

Worker Class 선언

class Worker(object):
    def __init__(self, input_data):
        self.input_data = input_data
        self.result = None

    def map(self):
        raise NotImplementedError

    def reduce(self, other):
        raise NotImplementedError

    @classmethod
    def create_workers(cls, input_class, path):
        workers = []
        for input_data in input_class.generate_inputs(path):
            workers.append(cls(input_data))
        return workers


class LineCountWorker(Worker):
    def map(self):
        data = self.input_data.read()
        self.result = data.count("\n")

    def reduce(self, other):
        self.result += other.result

Map Reduce 수행

def execute(workers):
    threads = [Thread(target=w.map) for w in workers]
    for thread in threads:
        thread.start()

    for thread in threads:
        thread.join()

    first, rest = workers[0], workers[1:]
    for worker in rest:
        first.reduce(worker)

    return first.result

def map_reduce(worker_class, input_class, path):
    workers = worker_class.create_workers(input_class, path)
    return execute(workers)

List Comprehension

2021-10-29T14:52:29+00:00


한 밤에 중앙 공원에서 …(럭키의 하루!)

map과 filter 대신에 리스트 컴프리헨션을 사용하자

리스트 a에 있는 각 숫자의 제곱을 계산할 경우

a = [1,2,3,4,5,6,7,8,9,10]
squares = [x**2 for x in a]
print(squares)
=> [1,4,9,16,25,36,49,64,81,100]

map을 사용하면 lambda가 필요해서 복잡해 진다

square = map(lamda x: x**2, a)

a 배열에서 2로 나누어 떨어지는 숫자만 제곱하는 경우

even_squares = [x**2 for x in a if x % 2 == 0]
print(even_squares)
=> [4, 16, 36, 64, 100]

내장 함수 filter를 map과 함께 사용하는 경우

even_squares_alt = map(lambda x: x**2, filter(labmda x: x % 2 == 0, a))
assert (even_squares == list(even_squares_alt)

딕셔너리와 세트에도 리스트 컴프리헨션에 해당하는 문법이 있다.

chile_ranks = {'ghost': 1, 'habanero': 2, 'cayenne':3}
rank_dict = {rank: name for name, rank in chile_ranks.items()}
chile_len_set = {len(name) for name in rank_dict.values()}
print(rank_dict)
print(chile_len_set)
=> {1: 'ghost', 2: 'habanero', 3: 'cayenne'}
=> {8, 5, 7}

home