2 added 161 characters in body
source | link

What you think about SOLID principles

Well, at least the constructor uses dependency injection, so the D from SOLID is applied here, I guess? ;-) But I assume your question is about the SRP, not about SOLID in general.

So to be serious, this design looks to me like someone wanted to have a "callback" or "hook" to be called whenever a User object is created (probably with the special intention to make sure the object exists also in a repository or another service is informed about the objects creation).

Actually, I think it is debatable if this really violates the SRP, (since it will be easy to nullify a call like userRepository.Save by passing a dummy repo). For that reason, howeverthe two additional parameters do not prohibit unit testing or reuse of that class in a context where the repo and/or service is not needed (which would be a clear sign of violating the SRP).

However, I think this violates the more fundamental KISS principle. The injected interfaces make the calling code more complicated. We don't see the whole surrounding code, but IMHO it is (almost) always possible to keep the domain objects completely clean of any callbacks or service calls, and let the surrounding environment handle these things. To to my experience, thatthis will lead to a system which is overall simpler, easier to understand and easier to maintain.

What you think about SOLID principles

Well, at least the constructor uses dependency injection, so the D from SOLID is applied here, I guess? ;-) But I assume your question is about the SRP, not about SOLID in general.

So to be serious, this design looks to me like someone wanted to have a "callback" or "hook" to be called whenever a User object is created (probably with the special intention to make sure the object exists also in a repository or another service is informed about the objects creation).

Actually, I think it is debatable if this really violates the SRP (since it will be easy to nullify a call like userRepository.Save by passing a dummy repo), however, I think this violates the more fundamental KISS principle. The injected interfaces make the calling code more complicated. We don't see the whole surrounding code, but IMHO it is (almost) always possible to keep the domain objects completely clean of any callbacks or service calls, and let the surrounding environment handle these things. To to my experience, that will lead to a system which is overall simpler, easier to understand and easier to maintain.

What you think about SOLID principles

Well, at least the constructor uses dependency injection, so the D from SOLID is applied here, I guess? ;-) But I assume your question is about the SRP, not about SOLID in general.

So to be serious, this design looks to me like someone wanted to have a "callback" or "hook" to be called whenever a User object is created (probably with the special intention to make sure the object exists also in a repository or another service is informed about the objects creation).

Actually, I think it is debatable if this really violates the SRP, (since it will be easy to nullify a call like userRepository.Save by passing a dummy repo). For that reason, the two additional parameters do not prohibit unit testing or reuse of that class in a context where the repo and/or service is not needed (which would be a clear sign of violating the SRP).

However, I think this violates the more fundamental KISS principle. The injected interfaces make the calling code more complicated. We don't see the whole surrounding code, but IMHO it is (almost) always possible to keep the domain objects completely clean of any callbacks or service calls, and let the surrounding environment handle these things. To my experience, this will lead to a system which is overall simpler, easier to understand and easier to maintain.

1
source | link

What you think about SOLID principles

Well, at least the constructor uses dependency injection, so the D from SOLID is applied here, I guess? ;-) But I assume your question is about the SRP, not about SOLID in general.

So to be serious, this design looks to me like someone wanted to have a "callback" or "hook" to be called whenever a User object is created (probably with the special intention to make sure the object exists also in a repository or another service is informed about the objects creation).

Actually, I think it is debatable if this really violates the SRP (since it will be easy to nullify a call like userRepository.Save by passing a dummy repo), however, I think this violates the more fundamental KISS principle. The injected interfaces make the calling code more complicated. We don't see the whole surrounding code, but IMHO it is (almost) always possible to keep the domain objects completely clean of any callbacks or service calls, and let the surrounding environment handle these things. To to my experience, that will lead to a system which is overall simpler, easier to understand and easier to maintain.