Hi Everyone, On Sun, Feb 19, 2017 at 2:04 PM John Porter <j...@designermonkey.co.uk> wrote:
> Hi Michael, > > Thanks for your response. I have read about, and personally discussed the > SOLID principles with Uncle Bob, and I do believe that there is more than > one final interpretation of those principles. I can see your points, but > raise you this: > > SRP says only that a `car` class should not implement both > responsibilities *by itself*! > > > Currently, the middleware proposal and current used implementation ask for > exactly that. That the middleware be responsible for the inbound and > outbound flow. Even if it is for the middleware to decide that for itself, > it is still a breach of SRP allowing a class to decide that. My point is > the choice should not be there in the first place, by way of defined > interfaces. > The middleware doesn't necessarily dictate where your behavior takes place. Follow Dependency Inversion and Interface Segregation and you can achieve a single responsibility for each class, even for the extra-strict (in my opinion) version of SRP/ISP you are presenting. If you want to have these concerns be separate, inject the behaviors as dependencies and treat the middleware itself as more of a behavior router. That way each of your individual behaviors are handled in individual classes. A good example of this in my mind is containers. We have the container PSR that is super minimal (has / get). That doesn't mean that a container won't also try to do dependency injection and automatic instance inflation all kinds of other stuff. In fact most of them WILL. They simply delegate those responsibilities / behaviors to a dependency and there-by avoid SRP/ISP/OCP issues. IMHO > My point about ISP is to follow the definition you stated. If we take away > the choice of multiple responsibilities from the middleware, then we must > separate the interfaces. And I do know that it is not about PHP interfaces, > but that is what they are for, along with the same in JAVA, and class > abstractions; they are used to define the contract between classes: Can > this middleware affect the request? Can this middleware affect the > response? That kind of question comes from the interface the class > implements. > The current state of PSR-15 as I see it doesn't prevent tracking what the middleware is doing in the course of a request. Since the DelegateInterface is an instance that a middleware stack is injecting, you can track pretty easily how far the request moves through the stack. Now if the issue is trying to preemptively know whether or not the middleware does this or that, PSR-15 currently doesn't cover inserting middleware into a stack. In my mind this is something that humans do so they should be aware of what the middleware does and is for when they add it to the stack. So with those two arguments in mind, can you provide an example where a middleware stack would need to be able to identify whether a middleware will be returning a response or a request or dieing without simply observing what happens when the request flows through the stack? Thanks for the interest and discussion, I'm very pleased with the state of the FIG these days, very constructive and interesting. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWX%3Dpnu4t3gA4F3GhQ9ikpqv7v6h5tyGUG7pmniF-s1FpA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
