Hi,
There is a way to make a protected method callable from a derived class but not overridable by making it FINAL.
Is there a way to do the opposite?
I.e. make a method overridable, but not callable by a derived class.
An example could be a protected abstract method that only the base class should call in a specific order or scenario.
The derived class is allowed or obliged to provide an implementation, but should never directly call the method.
It seems something like this is possible in c++ using "private virtual".
I was wondering if any construct in ABL could mimic this...
See https://stackoverflow.com/questions/414746/override-but-dont-call and https://stackoverflow.com/questions/29412477/java-method-only-callable-by-superclass
Sure, I gave the original problem another thought and in this case think I found a cleaner solution.
Nevertheless, I thought it was worth starting a discussion...
One other solution we thought off (but became redundant because of the refactoring) was to move the implementation of the method to another class (strategy pattern), and have that injected into the base class (composition!).
Hi Lieven,
What a fun OO is! I use *private* methods by default, no inheritance so no subtype polymorphism & protected whatever. No ridiculous 'abstract' nonsense. Public methods when needed. I'm overall not a fan of unit tests when units mean methods (for a start on some not too stupid criticism read rbcs-us.com/.../Why-Most-Unit-Testing-is-Waste.pdf), but I suppose you're already addicted to those green images beside each method and want to tell your manager about those high coverage percentages while your architecture is-a disaster anyway. Never *** up your architecture for testing purposes!
I want to be able to ruthlessly refactor your overcomplicated code and moreover not be hindered by your unit tests. Testing behaviours is not that bad.
There are c+ devs (and here I mean one of the most intelligent devs of c++ itself) that can and do without oo .. www.stlport.org/.../StepanovUSA.html (danger, don't click on that link).
But I'm sure you love complexity (it makes one feel intelligent, eh ;-).
Didn’t knew you could be so funny Stefan, thanks for sharing your thoughts… still, wonder why those dreams about ‘ruthlessly’ refactoring my poorly written code? :)
oh Jeez Marian, there are _so_ many things wrong about your reply ;) Maybe it's transference ? :)
@Stefan - I *love* complexity .. it means that there is still so much to learn, because I'm obviously still not perfect ..
If it is not obliged, a custom event should work for this case.
@jmls There is a lot to unlearn sometimes, and decomplect. Simplicity is hard enough.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."
"Simplicity is prerequisite for reliability."
(Dijkstra)
I don't want this thread to end up in another pro/con OO principles farce...
While I also try to favor composition over inheritance, even Bjarne Stroustrup mentions in the talk agent_008_nl recently referred to that inheritance still is an important tool in any OO developers toolbox either way...
Anyway, I'm rethinking the design of this particular piece of code.
It was based of an existing implementation, but might need some more refactoring to prevent the need for this *feature*...
Maybe you just don't need what you propose in your first mail. Maybe OO is possible without inheritance and subtype polymorphism. According to Stroustrup it is. And maybe you can program much more agile / simpler solutions without. I think it is that way (too much work to explain for now, watch f.e. the movie I postend earlier www.youtube.com/watch , this is from a spotify programmer and very well thought through).
I'm stuck myself with OO for the time being and want to make the best of it. That means a lot of disentangling / refactoring (for which I currently have a long during mandate). Without all complecting stuff life becomes easier.
Sure, I gave the original problem another thought and in this case think I found a cleaner solution.
Nevertheless, I thought it was worth starting a discussion...
One other solution we thought off (but became redundant because of the refactoring) was to move the implementation of the method to another class (strategy pattern), and have that injected into the base class (composition!).
Ask Progress for implementation of delegates. :)
For those of us who are not OO experts, what would a delegate provide from an ABL perspective?
It's a construct that allows a class to literally delegate a work outside the class implementation without passing an object. This avoids dependency. It's functionally similar to callback construct.
Ex.
Class A
METHOD CHAR MyInfo() . . .
classB.AskAnotherClassInfo(NEW DELEGATE(MyInfo)) // somewhere in class A
Class B
DELEGATE SomeMethod()
METHOD AskAnotherClassInfo(SomeMethod proxy)
DO:
var = proxy(). // will run class A's MyInfo
END.
Here, class B has no reference dependency on class A.
It’s a .net thing Jeff, you can look at it like as a function pointer or a 'single method interface’… avoiding dependency can well be achieved by using interfaces or events so it’s not like we can live without it but I do feel Mike’s pain here, lots of .net assemblies using this so in order to use those from 4GL one need to write wrappers in .net :(
Not that important, but delegates are not OO according to others. You find them in functional languages and multi-paradigm languages. "One example is C#, which includes imperative and object-oriented paradigms, together with a certain level of support for functional programming with features like delegates (allowing functions to be treated as first-order objects)" [View:https://en.wikipedia.org/wiki/Programming_paradigm:550:50]
Not wanting to hijack anything and going off-topic ;-) but
"Probably you will be surprised how similar functional and OO code is, and that most ideas are things you already know."
http://sidburn.github.io/blog/2016/05/20/introduction-to-functional-programming