4 ms·
By 'design patterns' I assume we're talking about following SOLID principles, which even when copied from other languages involves dependency injection, factory
by arenaninja 10y ago
By 'design patterns' I assume we're talking about following SOLID principles, which even when copied from other languages involves dependency injection, factory methods and singletons.
I agree that on some of these are a burden on PHP (mostly PSR-7), but as you mentioned that's the direction most languages/frameworks are following nowadays. It isn't necessarily good but frameworks and design patterns aren't about saving execution time, but saving development time and increasing maintainability by adhering to easy(ish) to follow concepts
On Rasmus, having met him once I'm not at all surprised that he thinks they all suck. I would disagree because I do like the Slim 3 framework although I wish it hadn't been an early adopter of PSR-7 because it feels like a heavy-handed solution to an infrequent problem. But I'm not sure we have good alternatives here. We can go back to spaghetti code or write a better framework
- thehardsphere 10y agoHere’s two alternatives: 1. Don't write object oriented PHP. Despite the promise it showed early on, history now tells us that "Object oriented" is not a guarantee for quality, nor does it prevent spaghetti code. 2. Write framework-compliant object oriented code in another language/runtime more suited to executing it (basically anything that doesn't try to live directly inside the Apache request/response cycle). You might not consider them "good" alternatives, but I think they are the choices a lot of people eventually end up choosing between. I generally agree that frameworks are good to use for saving developement time, but execution time matters. The performance penalty paid for some of these frameworks on PHP compared to the two alternatives above is large enough to negate the benefit for all but trivial cases.