Should PRIVATE STATIC be preferred over PRIVATE when... - Forum - OpenEdge Development - Progress Community

Should PRIVATE STATIC be preferred over PRIVATE when...

 Forum

Should PRIVATE STATIC be preferred over PRIVATE when...

This question is not answered

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?

All Replies
  • It’s of certain harm … classes with static members are not part of the -reusableObjects cache.
     
    And in the history of GUI for .NET there have been (now resolved issues) with mixing static members and hybrids.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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 :(

    As Mike said, better stay away off static unless all class’s methods are static like a pure helper object.

  • 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?

  • I hope not. As the instances are already there and not just created for the sake of that method.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • May I ask why would you want to keep others from calling those methods since these are idempotent and hence can cause any harm? 

    Lately I get pretty annoyed by any use of PRIVATE and FINAL… not that it makes it next to impossible to extend/unit test something but it bothers me the developer's claim that everyone should stay away of her/his preciously crafted code :)

    I guess it’s just me getting older though :(


  • Marian, it’s not allowing others to use your code that bothers with PUBLIC.
    It’s taking away your liberty to change those methods without breaking other people’s (people you might not even know) code.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Exactly Mike, and also that the code really isn't of much use outside the context of the current class.

  • Lieven De Foor

    Exactly Mike, and also that the code really isn't of much use outside the context of the current class.

    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 ;)

    , 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.

  • 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?

    That'd mostly depend on the number and type of instance members, and code in instance constructors. Makes things hard to predict.
    But if for example you decided the instance Constructor is a good place to pull a few thousand records into an instance-member temp-table, then yes you probably would see a substantial impact.
    If on the other hand you have only a small handful of properties and a default constructor, even a few hundred instantiations probably won't add more than a few milliseconds to the total running time.
    As far as loading the actual code goes: AFAIK any method, regardless of STATIC status or access level, is just another r-code Action segment. So you won't see a difference there.
    Well, actually, there might be a negative impact there if -mmax and -d are poorly tuned, because classes with static members would not release the resources they claim there. Thus more statics may lead to more swap space in the rcd* file being used, other r-code being unloaded and reloaded more frequently, etc.
  • 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 ;-)

  • 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).

    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...