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.
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.
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.
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 const member 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.
Things that generalize tend to lose the essence of context.
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...
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.
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.
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.
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.
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.