I don't see how this classes relate to a dependency chain.
EventHandler is no Gadget, its a "delegate".
And the controlWithItems would be useless as well, a control should, if it is a contrainer, have a child list.
I agree that 2 levels is to little, but actually there are definitely users that totally overdue it as well as too much extension does not help, often decoration is much more powerfull and flexible. BM has some very interesting internal classes that show how to use this mechanism usefully like the streamwrapper class which is extended by others.
And an article like that can only come from someone with no pure indepth OO knowledge like a C++ programmer.
I know quite some of them due to study and for some reason they always fall back to procedural the moment they face a problem that needs some real indepth OO knowledge ( -> patterns ) to solve intead of hacking.
the "Contradiction Leads to Confusion" is the largest joke I've heard since a long time. Even 1 semester students in computational science know WHY it must be like that if you want error free code. And some of them don't even know how to write a hello world where you can input your name!
But for those that don't know it: The idea is that you rely on fixed functionality which is clear specified on its functionality and interface. You can rely on this and that it does what it is meant to. But you must not know (-> use ) its inner working, there is no reason to, as you wanted to use the functionality, not its implementation.
Reason is that the implementation can change and by only using the functionality you ensure that other code is unaffected by it in the meaning of "you don't need to alter other code as well"
the moment you behave like that "great writer", you are doomed on the long sight as it will be impossible to work like that on a larger scale software codebase.
without OO, todays largescale software systems would be impossible, no mather how cleanly you would program.
Clean and stable multithreading would be even less possible, as the most powerfull mechanisms (monitor and the like) rely on objects, not on variable locks which are to easy to break.
the best one was that:
Welcome to the world of a real noob
EventHandler is no Gadget, its a "delegate".
And the controlWithItems would be useless as well, a control should, if it is a contrainer, have a child list.
I agree that 2 levels is to little, but actually there are definitely users that totally overdue it as well as too much extension does not help, often decoration is much more powerfull and flexible. BM has some very interesting internal classes that show how to use this mechanism usefully like the streamwrapper class which is extended by others.
And an article like that can only come from someone with no pure indepth OO knowledge like a C++ programmer.
I know quite some of them due to study and for some reason they always fall back to procedural the moment they face a problem that needs some real indepth OO knowledge ( -> patterns ) to solve intead of hacking.
the "Contradiction Leads to Confusion" is the largest joke I've heard since a long time. Even 1 semester students in computational science know WHY it must be like that if you want error free code. And some of them don't even know how to write a hello world where you can input your name!
But for those that don't know it: The idea is that you rely on fixed functionality which is clear specified on its functionality and interface. You can rely on this and that it does what it is meant to. But you must not know (-> use ) its inner working, there is no reason to, as you wanted to use the functionality, not its implementation.
Reason is that the implementation can change and by only using the functionality you ensure that other code is unaffected by it in the meaning of "you don't need to alter other code as well"
the moment you behave like that "great writer", you are doomed on the long sight as it will be impossible to work like that on a larger scale software codebase.
without OO, todays largescale software systems would be impossible, no mather how cleanly you would program.
Clean and stable multithreading would be even less possible, as the most powerfull mechanisms (monitor and the like) rely on objects, not on variable locks which are to easy to break.
the best one was that:
A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP—often by simply copying and pasting.
Welcome to the world of a real noob