11–20 of 35 posts
Earlier quoted context omitted.
Because a function is not a contract enough - it doesn't have a strong name at point of injection. But yeah, pure functions should be used way more often.
Does everything need to be dependency injected ? Sometimes it seems this is more important than code that works.
I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas. S -> don’t write spagetti code. O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality. L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’…
Its not a special focus; the SRP is a bigger deal and focuses on objects.
OTOH, violations of the ISP force violations of the SRP, because an interface with unnecessary methods means that objects which must implement the interface will be forced to have unnecessary methods.
Screw up SRP in a leaf class and you've created a problem for that class; screw it up in a branch class or an interface and you've screwed up a wider swath of the code base. As the LSP encourages composition over inheritance, if you are doing the rest of SOLID, interfaces are a bigger opportunity to screw up but chunks of the code base at once than classes.
I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas. S -> don’t write spagetti code. O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality. L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’…
> Sure, mega-interfaces are bad... I guess... but so are objects with massive sets of methods on them. Why the special focus on interfaces? Its not a special focus; the SRP is a bigger deal and focuses on objects. OTOH, violations of the ISP force violations of the SRP, because an interface with unnecessary methods means that objects which must implement the interface will be forced to have unnecessary methods. Screw…
Many languages's standard libraries have stuck methods for mutation into the base interface for collections of objects. This makes it awkward (at best) to try and use immutable collections. Either you create your own base interface, which makes you incompatible with the rest of the standard library, or you inherit the standard interface and then do something like throw an exception when someone attempts to mutate your collection, and just hope that never happens in production.
Earlier quoted context omitted.
Because a function is not a contract enough - it doesn't have a strong name at point of injection. But yeah, pure functions should be used way more often.
Does everything need to be dependency injected ? Sometimes it seems this is more important than code that works.
I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas. S -> don’t write spagetti code. O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality. L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’…
Dependency inversion makes things unit testable.
>testing is good right?
All other things being equal, wouldn't a form of testing that doesn't require rearchitecting your code be better than one that doesn't?
Oh good example. It shows everything that's wrong with OO thinking I could split the file interface like this, thinking that some modules will want to read only, some people will want to write only (in rare cases you want trim only, but that is obvious except to "enterprise architects" apparently) Except it's splitting hairs. And my readers can ignore the write interface and my writers can ignore the read interface a…
Caller has no problem just ignoring the methods that it doesn't need. But the implementer doesn't have that possibility. If you have a read-write interface and a read-only source, you need to resort to subpar solutions like throwing an exception.
Earlier quoted context omitted.
Does everything need to be dependency injected ? Sometimes it seems this is more important than code that works.
You can inject e.g. a Func or an IAdder interface. Although they are for the sake of example equivalent, I prefer the latter for several related reasons: it gives the DI container a specific type name to work with and avoids complex setup there, it gives the person reading the code a lot more to work with when trying to understanding what the injected thing is used for, and Func is very general - not all functions wi…
Earlier quoted context omitted.
You can inject e.g. a Func or an IAdder interface. Although they are for the sake of example equivalent, I prefer the latter for several related reasons: it gives the DI container a specific type name to work with and avoids complex setup there, it gives the person reading the code a lot more to work with when trying to understanding what the injected thing is used for, and Func is very general - not all functions wi…
Again, why does everything need to be dependency injected? Why not a simple function that adds two numbers? I see these codebases where everything is abstracted two and three times and I don't understand what this achieves other than adding a ton of complexity for even simple things.
But injection is done for testability and flexibility.
Standardizing tools and conventions in a shop is how you save time. Independent bolts may not fit independent wrenches so that you have to reinvent both. Bundling tools and parts into "kits" helps ensure they fit together well. There's a balance between part independence and kit standardization. Experience and analysis is needed to weigh that trade-off well.