When a private method in a class has no dependencies on any instance members, you can declare it private static.
In some languages this could (theoretically) improve performance (https://stackoverflow.com/questions/202631/performance-of-using-static-methods-vs-instantiating-the-class-containing-the-me).
Is this the case as well in ABL or is replacing private by private static (when possible) of no use?
This is a clear sign the method does not belong to that class in the first place and should be moved out to a more appropriate place (helper). It often happen during development, we don’t always have the time to come up with a proper decomposition especially in today’s agile world :(
Sometimes you don't want others to call these methods, and by making them private static to the class you keep them out of reach.
Creating a helper causes these to become public.
I've always been wary of public static (can't be put in an interface, can't be mocked), but for private static those objections don't really come into play...
Note that the linked page and related ones claim a comparatively big performance gain when comparing a invoking a static method with "instantiating -> invoking in instance method -> eventual garbage collecting" for a single method call.
So you're comparing "relying on the language and runtime to ensure the code only gets loaded once" with "coding to (potentially) flood the runtime with garbage".
The performance difference won't be in invoking the method itself, it will be in the overhead surrounding the invocation.
Instantiating the class once and keeping a reference around would get you a similar (theoretical) performance gain. That'd be the "explicitly code to ensure the code only gets loaded once".
In my specific case the class will have a couple hundred instantiations, so perhaps in that case the single static vs multiple instance method "instantiations" does have a noticeable impact?
May I ask why would you want to keep others from calling those methods since these are idempotent and hence can cause any harm?
Exactly Mike, and also that the code really isn't of much use outside the context of the current class.
[quote user="Lieven De Foor"]
Exactly Mike, and also that the code really isn't of much use outside the context of the current class.
[/quote]
Lieven, you did said it's not using any of the current class's context so it might not be of much use outside of this now but its most probably not something that pertains to that class functionality either. But then again, if no one else will use it then no one will be affected when you change those so those public methods won't break other's people code ;)
[mention:6e3b17cb0ff148039a2aabb4c7834ce4:e9ed411860ed4f2ba0265705b8793d05], ruling out PRIVATE does not mean everything should be PUBLIC either... me preference is never use FINAL and use PROTECTED for anything else that is not meant to be PUBLIC.
[quote user="Lieven De Foor"]
In my specific case the class will have a couple hundred instantiations, so perhaps in that case the single static vs multiple instance method "instantiations" does have a noticeable impact?
Well in fact it does pertain to the class' functionality, but not to its state. I just don't want to pollute the class hierarchy with a helper class that's only there for a single consumer and has no interesting code to any others.
I'm thinking quite the opposite about the use of FINAL/PROTECTED recently and would favor using final with composition/delegation and as little protected members as possible (private and public only).
Thanks Frank, that's some useful info to take into account or run tests with.
Perhaps someone from Progress development could tell, from experience or knowledge of the interior design, if there is a clear winner or if this is just a nonsense discussion, then by all means tell ;-)
[quote user="Lieven De Foor"]
I'm thinking quite the opposite about the use of FINAL/PROTECTED recently and would favor using final with composition/delegation and as little protected members as possible (private and public only).
[/quote]
Hmm, I see now how mentioning PROTECTED made you thing inheritance vs. composition is what I had in mind but this is not the case nor will FINAL will favour composition albeit it will prevent inheritance :)
Using PROTECTED instead of PRIVATE will let you write unit tests for those methods by simply extending the class for test purposes and imho there is really no gain in forbidding other developers extend/change functionality of your code if they see fit.
We could start a whole other discussion on that topic here, but let's not go that way, at least not in this thread ;-)
Writing unit tests for protected members is indeed a (or the only?) way to test implementation.
I think you just have to be pragmatic and use what works best for a specific situation...