artificial_artwork.utils.proxy

Complexity

Total Complexity

4

Size/Duplication

Total Lines	49
Duplicated Lines	0 %

Importance

Changes

0

4 Methods

Rating	Name	Duplication	Size	Complexity
A	Subject.request()	0	3	1
A	Proxy.__init__()	0	2	1
A	RealSubject.request()	0	2	1
A	Proxy.request()	0	8	1

from abc import ABC, abstractmethod


__all__ = ['RealSubject', 'Proxy']


class Subject(ABC):
    """
    The Subject interface declares common operations for both RealSubject and
    the Proxy. As long as the client works with RealSubject using this
    interface, you'll be able to pass it a proxy instead of a real subject.
    """

    @abstractmethod
    def request(self, *args, **kwargs) -> None:
        raise NotImplementedError


class RealSubject(Subject):
    """
    The RealSubject contains some core business logic. Usually, RealSubjects are
    capable of doing some useful work which may also be very slow or sensitive -
    e.g. correcting input data. A Proxy can solve these issues without any
    changes to the RealSubject's code.
    """

    def request(self, *args, **kwargs) -> None:
        raise NotImplementedError


# TODO use generic typers to define RealSubject at runtime
# then the client code will not have to overide the RealSubject
class Proxy(Subject):
    """
    The Proxy has an interface identical to the RealSubject.
    """

    def __init__(self, real_subject: RealSubject) -> None:
        self._real_subject = real_subject

    def request(self, *args, **kwargs) -> None:
        """
        The most common applications of the Proxy pattern are lazy loading,
        caching, controlling the access, logging, etc. A Proxy can perform one
        of these things and then, depending on the result, pass the execution to
        the same method in a linked RealSubject object.
        """
        return self._real_subject.request(*args, **kwargs)