Writing code is the easy part of programming. Our aspiration is to write clean, maintainable code that reads like well-written prose. Yesterday was...
For further actions, you may consider blocking this person and/or reporting abuse
Bob is a great speaker and very convincing but in practice much of his advice is really useless. Dependency inversion is an illusion. Just because class A now no longer depends on class B (in the java imports sense) does not mean class A will not fail when class B fails. The interface they both now „depend“ on does not break or change the real dependence. It’s smoke and mirrors as is OCP. No program can be closed for modification. It can only be closed for a very narrow class of previously anticipated extensions. Sounds impressive, in reality everything can and must change.
I agree with you on two counts:
However, I don't think dependency inversion is supposed to mean that client code will still work if implementer code breaks. Correctly me if I am wrong, the interface is meant to be a contract between the client and the implementer. The contract doesn't do the work. It is used to express what the client expects and what the implementer must satisfy. If the implementer code breaks, we just go out there and get someone else to bid for that contract.
Now, it is certainly true that both side of the abstraction barrier change way too often in reality(Or is it ?). I wonder is it really better with/without the concept of contract. Certainly in other aspects of our lives, when things are serious, we always have this concept of contract in place. Do we need them in code? I don't know...
Just my two cents.
I've listened to a few of his talks but most of them are just rants. His books are allright, but really Uncle Bob doesn't even practice his own methods because he doesn't code.
Think before you speak, boy ;P.
github.com/unclebob/fitnesse
Did you even look at the contributions before you posted? I'll give you a hint Uncle Bob isn't the main contributor. Nice try though. Check before you post, boy. ;P.
Dammit! But... he's so convincing!
When you are the maintainer of a repository that doesn't mean you have to have the most commits. That is a fallacy.
Indeed. It's that exact reason why I'm not a fan of final classes and the classic builder pattern: they assume that the creator of the code is able to predict the future with perfect precision.
Disagreed:
finalindicates that the design was not intended for extension.Yes, and when that's part of a framework, future users of the framework can be pushed into a corner because the framework designer e.g. did not intend/foresee a new security approach that doesn't use username and password but 1 string or 3 strings.
When using 'final' on a class you inherently intend to not be future-proof, whether you realize it or not.
You are right. The user is pushed into a corner.
Being future proof should be a conscious decision (because its cost and risks are non-negligible), not the developer's to make.
To me, it's comparable to having a
constmember function/parameter/local that guarantees that my code does what I want it to do.Unless I declare a public class
final, It's harder for me to guarantee the working of the framework (cf. fragile base class). If I want you to extend behavior, I'll make you inject an interface you can implement.The middle ground is I give you an abstract base class to extend. Consciously.
Especially when designing bigger systems, dependency management becomes more important. He did write some good things about architecture, too.
blog.cleancoder.com/uncle-bob/2012...
I like to ask you something about the mechanics of dependency injection?
in dot.net, you configure what implementation to use and inject in a
Startupclass. in testing or different environment you can use different implementations of thestartupclass and thus choose the implementation. this is to have some dependency configuratiob.in java spring framework there js a dependency injection configuration as xml.
in angular with typescript, there are modules fikes within the folder structure.
an other approach, other then using a framework, is to do dependency injection manually. some code know how to wire this app together. or even dependencies get passed into functions,... basically DI all over the code.
In JS for testing it is also pissible to use modules like
rewire, that change the implementation of therequiremethod to provide a mock into the module, sometimes used in testing.what are your opinions on these mechanics? do you prefer it more abstract in a framework, or more direct with more hand work?
I do you one better, Where is Uncle Bob? 😁
Uncle Bobin my country is a person who selling Fried Chicken Chop in a RV.