Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider mentioning SRP style of classes together with DI #233

Open
sobolevn opened this issue Feb 2, 2020 · 4 comments
Open

Consider mentioning SRP style of classes together with DI #233

sobolevn opened this issue Feb 2, 2020 · 4 comments

Comments

@sobolevn
Copy link

sobolevn commented Feb 2, 2020

This chapter describes a lot of ways to handle Dependency Injection in Python. (It even mentions dependencies 馃帀 )

But, it does not mention SRP-styled classes. They are originally invented in Ruby (dry-system), but in my practice they are perfectly usable in Python (providing type-safe DI and declarative style):

from typing import final
from attr import dataclass

@final
@dataclass(frozen=True, slots=True)
class SendTodaysPostcardsUsecase(object):
    _repository: PostcardsForToday
    _email: SendPostcardsByEmail
    _analytics: CountPostcardInAnalytics

    def __call__(self, today: datetime) -> None:
        postcards = self._repository(today)
        self._email(postcards)
        self._analytics(postcards)

This way we don't have an explicit constructor. We only have a single public method with possibly other protected ones.

What do you think?

Original article (using punq as an implementation): https://sobolevn.me/2019/03/enforcing-srp
dry-rb/dry-system docs here: https://dry-rb.org/

@simkimsia
Copy link

Adding a +1 because I would also like to know @hjwp or @bobthemighty thoughts on this

@Bryant-Yang
Copy link

+1 for the article, broadens my mind.

@bobthemighty
Copy link
Contributor

I don't have a strong opinion here. Using a dataclass instead of an ordinary Python class saves a little bit of boiler plate, but I think it's a question of taste. I don't think it's wrong in any way, and there's something nice about having service classes be immutable, because it saves you from cheating with state.

I would, though, like to challenge the assertion in the article that "combin[ing] data and behavior together ... is a clear violation of SRP" since the SRP is specifically a principle of object-oriented software, where the combination of data and behaviour is axiomatic.

Even in the class listed above, the UseCase object has data, it's just immutable, so I don't think it has any fewer responsibilities than any other way of building a use case.

Neat idea, though, and of course you get bonus points for using punq 馃槃 鉂わ笍

@sobolevn
Copy link
Author

sobolevn commented Apr 23, 2020

object-oriented software, where the combination of data and behaviour is axiomatic

Please, don't take it seriously from a functional programmer 馃槅
It was more like a pun!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants