Yeah basically Object A is TDialog and it's Abstract. Object B is a TDialogYesNo. Both have a Manage() method. B.Manage() calls Super.Manage() and that's fine.
So I wanted an Object C which was a variant of TDialogYesNo with different buttons and text layout BUT I can't alter Object B (TDialogYesNo) because it's part of my framework and other people need it. B.Manage() won't work properly for my new Object C, so I needed to call A.Manage() then some extra code for the new Object C.
Sometimes the problem with design is that once you've made something and released it to the public, you can't really go and change the way it works in a big way or you break their code. It's not the same as sitting down and designing everything from scratch OR being able to refactor your design later.
You *can* change the way it works internally though and that's why I added a ManageCore() method to Object A which A.Manage() calls. Then in C.Manage() I call ManangeCore and then my own code, which works fine because Object B doesn't override A.ManageCore() only A.Manage(). Make sense?
So I wanted an Object C which was a variant of TDialogYesNo with different buttons and text layout BUT I can't alter Object B (TDialogYesNo) because it's part of my framework and other people need it. B.Manage() won't work properly for my new Object C, so I needed to call A.Manage() then some extra code for the new Object C.
Sometimes the problem with design is that once you've made something and released it to the public, you can't really go and change the way it works in a big way or you break their code. It's not the same as sitting down and designing everything from scratch OR being able to refactor your design later.
You *can* change the way it works internally though and that's why I added a ManageCore() method to Object A which A.Manage() calls. Then in C.Manage() I call ManangeCore and then my own code, which works fine because Object B doesn't override A.ManageCore() only A.Manage(). Make sense?