Static Class Code Libraries (or Smarter Ways to Manage Business Logic) - Forum - OpenEdge General - Progress Community

Static Class Code Libraries (or Smarter Ways to Manage Business Logic)

 Forum

Static Class Code Libraries (or Smarter Ways to Manage Business Logic)

This question is answered

Hello, pretty new to 4GL and this site. Searched a bit but couldn't seem to find anything I need.

My company is currently rewriting programs to GUI and trying to re-architecture the code base along the way. We are currently writing Functions inside of Include Files, grouped by category (convert temp table to .CSV, determine X/Y/Z of F, etc).

Coming from a college Java background, static classes (like Java.Math) make more sense to me, as .R code size is rapidly becoming an issue, and I think that compiled classes would exist in their own .R files (right? I couldn't find anything contrary to that point).

The end goal, from what I can tell, is:

  • First and foremost, a structured library of functions to prevent re-inventing the wheel
  • Compile-time argument checking (.p run-time argument checking is tedious)
  • Easy compilation maintenance (keeping track of what uses Function F and recompiling everything seems tedious)
  • Encapsulated (include files can't use same variable names as main programs is one "gotcha" we found)
  • Ease of or even self-documentation (just found out about prototypes today but I'd prefer private methods instead of saying "don't use this function")

Thanks for any help or references! I apologize if the answer is "read more!"

Verified Answer
  • >We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown
    > Eclipse and were not impressed, though I have years of experience with it for Java.

    Later versions of PDSOE (the new name for OE Architect) are much better in the 11.x family – better functionality, better performance. There is, of course, nothing preventing you from using N++ or Sublime Text or a bunch of other editors, and compiling using Ant or something similar.

    > The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we
    > would use an object (ideally).

    Easily doable in OOABL (ooh-able?). Even in 10.2B, IIRC.

    >That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight.
    >Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer
    >muses solutions that beg for OO but he is not too familiar with it.

    One of the great things about OOABL is that it coexists almost perfectly with procedural ABL, and I suspect that most procedural ABL programmers would easily be able to use objects in their code (there are already analogues like using the SESSION handle or THIS-PROCEDURE or whatnot, which have properties/attributes and methods on them).

    Adding new utilities or encapsulating existing libraries in OO might be a good way to introduce OO into your applications. There are also usually one or more talks and workshops at the PUG Challenges and Progress Exchange on getting started with OO (Tim Kuehn has a perpetually-popular workshop on this).

    For content from the US event, go to http://pugchallenge.org/downloads.html  (many years' worth). For the EU version, http://pugchallenge.eu/sessions_2013.html for last years' content (this is one area where the US version beats the EU version :)

    >So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given >some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like
    >FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be
    >very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

    If you have Java experience designing business app you should be good. The language reads very much like Java or C# and has most of the functionality those languages do (there are certainly exceptions, some large, but generally you should be able to Get Stuff Done).

    The other thing you will miss is the availability of public, commonly-used class libraries to help you do things like ORM or whatnot.

    HTH,

    -- peter

     
     
     
     
    From: bgourdie [mailto:bounce-bgourdie@community.progress.com]
    Sent: Tuesday, 14 October, 2014 10:38
    To: TU.OE.General@community.progress.com
    Subject: RE: [Technical Users - OE General] Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
     
    Reply by bgourdie

    Sorry for the lack of information; I wanted the first post to be short enough.

    We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown Eclipse and were not impressed, though I have years of experience with it for Java.

    We are not using an Appserver nor even SmartObjects. Everything is run off a server using a terminal (old system) or icons pointing to graphical programs and reports (new system). I don't really know what else to say here.

    The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we would use an object (ideally).

    That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight. Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer muses solutions that beg for OO but he is not too familiar with it.

    So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

    Thanks for all the thoughtful conversation and links!

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

All Replies
  • Hi,
    You can use classes and write Object Oriented code in the OpenEdge ABL.
    See link to the manual.

    Which OpenEdge version are you using?
    Which tool are you using to write or maintain your code?

    Currently the preferred way is using "Progress Developer Studio for OpenEdge". This is an eclipse based development environment.

    Kind regards
    Tjerk
  • You need to bring in someone who'se done the kind of code modernization you're working on. For one, I would strongly suggest you put all your functions in classes as methods instead of using include files - this will make life a _lot_ easier down the road.

    As for static classes - they have their place, however because their lifecycle is scoped to the session, they bring a number of issues with them that you'd be better off avoiding wide-spread use of them.

  • "I think that compiled classes would exist in their own .R files (right? I couldn't find anything contrary to that point)."

    You are absolutely right with that observation. Each class is compiled into it's own R-Code.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Tim Kuehn

    As for static classes - they have their place, however because their lifecycle is scoped to the session, they bring a number of issues with them that you'd be better off avoiding wide-spread use of them.

    I have the impression that the OP has experience with static classes in Java. They have their place there and here. For utility classes (that become part of the extensions of your personal ABL) they are a good vehicle. And the life time is typically not an issue for those classes as you need them the whole duration of the application anyway.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • I share Tim's concern. Mike is right, but OP suggests the use of static classes as a replacement for more than just utility classes I fear. A lot more is possible with the 4GL, I recommend OP to take a look at the possibilities of an inversion of control container (open source) and dependency injection written in 4GL:

    community.progress.com/.../998.oeri-dependency-injection-container-injectabl.aspx

    github.com/.../InjectABL

    + the autoedge|the factory framework (for coding examples):

    community.progress.com/.../974.autoedgethefactory-getting-started.aspx

    --

    Kind regards,

    Stefan Houtzager

    Houtzager ICT consultancy & development

    www.linkedin.com/in/stefanhoutzager

  • I didn’t expect you not to disagree with me. Beg my pardon, when I get the feeling that the OP has OO experience, I tend not to put his question down like a stupid boys question like some others tend to do in forums.
     
    But I must say it really surprises me, that you put the math capabilities of the  ABL (the OP’s sample) above the math capabilities of the OP.
     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Mike, an invitation for a mudfight to me personally is not in the interest of OP. You purposely misinterpret my intentions.

    OP states "My company is currently rewriting programs to GUI and trying to re-architecture the code base along the way. We are currently writing Functions inside of Include Files, grouped by category (convert temp table to .CSV, determine X/Y/Z of F, etc).". Het proposes to use static classes instead. A pointer to some more possibilities of the 4GL is not that bad, is it? After all he states himself he is pretty new to 4GL.

  • Hi Bret,

    Is someone guiding you to modernize the application? Since you are new to 4GL/ABL it would be good to set the basics correct and talk through the do's and don'ts.

    Did you hear about OERA (OpenEdge Referential Architecture).

    It scares me a bit that your company still uses include files to define utility or helper functions/methods. But if I read your post it also scares you a bit :).

    I agree with Mike and Tim. Static methods are great to use but need to be used carefully. A common mistake here is not define correctly record scopes. In general I would say use static methods for utility classes where you don't have data access. When you have data access it would be better to have business entities and an implementation of singleton classes. (OERA)

  • On Tue, Oct 14, 2014 at 3:02 AM, Mike Fechner
    wrote:
    > I didn’t expect you not to disagree with me. Beg my pardon, when I get the
    > feeling that the OP has OO experience, I tend not to put his question down
    > like a stupid boys question like some others tend to do in forums.

    The OP may have OO experience, however there are run-time
    considerations when doing ABL code which are different from Java
    run-time considerations. For instance, upgrading an appserver-based
    application, where the "scope of the session" is the agent's lifetime,
    not a single user's session. Using statics in that scenario has caused
    lots of problems when it's time to replace static-based or dependent
    code with something else, particularly if TT changes are involved.

    --
    Tim Kuehn: Senior Consultant - TDK Consulting Services
    Ontario PUG President
    PUG Challenge Americas Executive, Program Committee Chair

    Skype: timothy.kuehn
    Ph: 519-576-8100
    Cell: 519-781-0081
  • I still believe we need to learn more from the OP about what he intended in those statics.
     
    What runtime considerations are you talking about ABL vs. Java that are relevant for static classes in particular? The ABL is slower in loading classes compared to Java and .NET. That’s a fact and that leads to a more important role of temp-tables and ProDatasets in modern architectures.
     
    But especially with static classes, the overhead in instantiation is pretty much ignorable.
     
    We use a hand full of utility classes that are static. We consider them extensions of the language. And I don’t have problems with that.
    All framework and business logic classes are non static. That’s a different domain and can IMHO be implemented differently.
     
    Von: Tim Kuehn [mailto:bounce-timk519@community.progress.com]
    Gesendet: Dienstag, 14. Oktober 2014 12:10
    An: TU.OE.General@community.progress.com
    Betreff: Re: [Technical Users - OE General] AW: Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
     
    Reply by Tim Kuehn
    On Tue, Oct 14, 2014 at 3:02 AM, Mike Fechner
    wrote:
    > I didn’t expect you not to disagree with me. Beg my pardon, when I get the
    > feeling that the OP has OO experience, I tend not to put his question down
    > like a stupid boys question like some others tend to do in forums.

    The OP may have OO experience, however there are run-time
    considerations when doing ABL code which are different from Java
    run-time considerations. For instance, upgrading an appserver-based
    application, where the "scope of the session" is the agent's lifetime,
    not a single user's session. Using statics in that scenario has caused
    lots of problems when it's time to replace static-based or dependent
    code with something else, particularly if TT changes are involved.

    --
    Tim Kuehn: Senior Consultant - TDK Consulting Services
    Ontario PUG President
    PUG Challenge Americas Executive, Program Committee Chair

    Skype: timothy.kuehn
    Ph: 519-576-8100
    Cell: 519-781-0081
    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Stefan, despite your usual unqualified „Bratwurst“ vs. “Frikandel” posts you won’t get me down on that level.
    Not sure what you refer to.
    Von: agent_008_nl [mailto:bounce-agent_008_nl@community.progress.com]
    Gesendet: Dienstag, 14. Oktober 2014 09:27
    An: TU.OE.General@community.progress.com
    Betreff: RE: [Technical Users - OE General] Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
     
    Reply by agent_008_nl

    Mike, an invitation for a mudfight to me personally is not in the interest of OP. You purposely misinterpret my intentions.

    OP states "My company is currently rewriting programs to GUI and trying to re-architecture the code base along the way. We are currently writing Functions inside of Include Files, grouped by category (convert temp table to .CSV, determine X/Y/Z of F, etc).". Het proposes to use static classes instead. A pointer to some more possibilities of the 4GL is not that bad, is it? After all he states himself he is pretty new to 4GL.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • OERA is good to name. Very short on that: www.progress.com/.../ds-OpenEdge-Reference-Architecture.pdf

    There are several frameworks written according to it, like the autoedge|the factory (the most intelligent written one that I saw, I based mine on the backend part of it). Opensource: http://www.quarix.net/

    And of course there are several of these frameworks for sale (mine also ;-).

  • Depending in which geography you live, you might register for the EMEA PUG Challenge conference (standard registration closing tomorrow): http://pugchallenge.eu
    The conference is a great place to learn about OOABL, modernization options, frameworks ...
    A few framework vendors will also be exhibiting and presenting there.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • On Tue, Oct 14, 2014 at 6:28 AM, Mike Fechner
    wrote:
    > I still believe we need to learn more from the OP about what he intended in
    > those statics.

    More information is always good.

    > What runtime considerations are you talking about ABL vs. Java that are
    > relevant for static classes in particular?

    Upgrading systems running "old" appservers.

    > We use a hand full of utility classes that are static. We consider them
    > extensions of the language. And I don’t have problems with that.

    It depends on how the OP designs his system, where the statics are
    used, and what kind of upgrade mechanism they follow. As I mentioned,
    the static lifecycle is to the appserver agent's life, not the user's
    session life, which makes upgrading them problematic. This was from a
    conversation I had with Mary a while ago where I related that losing a
    db connection resulted in a session reset for connect clients, and she
    wondered if that could be used to upgrade appserver agents.


    --
    Tim Kuehn: Senior Consultant - TDK Consulting Services
    Ontario PUG President
    PUG Challenge Americas Executive, Program Committee Chair

    Skype: timothy.kuehn
    Ph: 519-576-8100
    Cell: 519-781-0081
  • “Upgrading systems running "old" appservers.”
     
    Not sure what you mean with „old“ AppServers.
     
    You think trimming AppServer agents every now and then is a bad thing? If it’s static or not – if you load classes into the memory of the AppServer and don’t know which classes in memory are from which release of the server code base (some loaded before your on the fly update, some loaded after your on the fly update) that sounds like a nightmare came true.
     
    On the other hand, the nature of the static utility classes may allow to update them less frequently than actual business logic. So once a year, I believe that trimming AppServer agents is o.k.. Others may actually be using the auto-trim feature of AppServer agents – without lacking any scalability.
     
    Aren’t we making too much assumptions already about what the poor OP is intending to do?
     

     

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.