OOOERA - Forum - OpenEdge Architecture - Progress Community
 Forum

OOOERA

  • Statement: "OOABL works best (read: most

    efficient) in a data driven architecture, where data

    is decoupled from behavior and data is passed through

    the tiers in temp-table format."

    Apparently, we don't have a consensus on this

    principle. In fact, I would say that the whole

    notion of decoupling data and behavior was

    antithetical to the principles of OO.

    This is not my opinion nor my preference. It's my question to John (PSC). What's the correct usage of OOABL, since ABL is a data centric and transactional language with its buffers, buffer scoping, temp-tables, etc. Is the OOABL suitable for creating (lots of) entity classes knowing the internal implementation of OOABL and missing a garbage collector?

  • I don't know that I think it

    necessarily should be PSC's job in general or John's in specific to

    answer the question. Their track record on real world best

    practices isn't exactly stellar. I don't see any reason why we

    can't be the ones to determine how it is that we want to use the

    language and to ask them to correct any deficiencies which get in

    the way of our using it the way we think it should be used. If

    there is some real performance issue with using entity classes,

    let's experiment and see what it is. As a stupid little exercise I

    created a class with four properties, which, of course, includes

    the implicit getter and setter methods for those properties. That's

    about 2.6K compiled. If I define a .p with a four column, one row

    temp-table and procedures to set and get the values, that is about

    6.9K ... so far we are ahead with the class approach.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • The webinar recording and the PPT of the slides have now been posted

    http://www.psdn.com/library/entry.jspa?entryID=2233

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • The webinar recording and the PPT of the slides have

    now been posted

    http://www.psdn.com/library/entry.jspa?entryID=2233

    Thanks Thomas, this presentation answers most of my questions.

    "...

    + ABL does not specifically support true objects as data representations

    - No collections

    - Relational joins between related data elements

    - Cannot pass an object as a parameter

    + But – mapping relational physical data to objects and back is avoidable overhead

    ..."

    Hehe... no real support for using entity classes, but who cares, "mapping... is avoidable overhead"

    It really feels like ABL didn't advance overtime when I look at constructs like this:

    {&PREFIX-NAME}{&COMPONENT-NAME}{&PACKAGE-NAME}{&PREFIX-NAME}{&COMPONENT-NAME}{&PREFIX-NAME}{&PACKAGE-NAME}{&PREFIX-NAME}{&COMPONENT-NAME}{&PREFIX-NAME}{&COMPONENT-NAME}{&METHOD-NAME}{&PARAM-LIST}

    What on earth are you going to save with this include? It looks like the 3rd algorythm in launching the spaceshuttle. Do you understand what's going on when you don't have the include and see this in your business logic:

    {templates/fetchdata_params.i}{templates/apicode.i}

    This presentation tells me OOABL will never be a serious step forward in productivity. It has it's place, sure, but this is not the breakthrough I was hoping for...

  • The collection piece I think is irrelevant since I have already demonstrated that one can implement them in ABL code.

    The cannot pass as parameter ... is really only across the wire and doesn't actually bother me much since it appears that marshalling and demarshalling via XML is possibly faster anyway.

    The real core issue here is the OO vs DOH approach. I guess it is pretty clear where I stand on not seeing the hybrid approach as a virtue.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • It feels like ADM with new wrappers.....

  • But, I don't think the model

    presented in this presentation is the only one possible with OO

    ABL. I think that a better implementation can be done; this just

    isn't it.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • But, I don't think the model presented in this

    presentation is the only one possible with OO ABL. I

    think that a better implementation can be done; this

    just isn't it.

    Maybe. But in that case you will probably end up fighting the language, something we learned the hard way with the ProDataSet for instance.

    This is for instance illustrative:

    IF NOT VALID-OBJECT(sessionObject) THEN

    FatalError( "Session management service not found!").

    ELSE

    servicemgr = CAST (sessionObject, service.servicemgr).

    END CONSTRUCTOR.

    METHOD PUBLIC VOID FatalError (pcMessage AS CHAR):

    MESSAGE "Fatal error!" SKIP pcMessage VIEW-AS ALERT-BOX ERROR.

    END.

    What do you want with a messagebox on the server? I want to throw an exception here. I can't of course, I can do a "RETURN ERROR", but that hasn't proven to be a very robust construct.

  • John, I think this is an area where we have very different opinions ... so I'm trying to advocate mine. It is obviously a good thing to allow people to mix and match, but you make it sound like a goal, i.e., the preferred target. In fact, your summary in the webinar seemed to be making that point explicitly that using this approach avoided the traditional OO coupling issues with the RDBMS.

    "Mix and match" can mean a couple of things here. Where the mixing of classes and procedures as types of ABL source files is concerned, I would suggest that in new development at least, classes have pretty much supplanted at least persistent procedures as a programming mechanism (this is not necessarily a view that is universally held -- yet). There are a few specific feature areas such as PUB/SUB that do not have their equivalent in classes yet, but those are being addressed. But of course, an unavoidable part of just about any real situation is migration of at least a part of an existing application to a changing world, and the fact that you can do development in classes and intermix that flexibly with existing procedures certainly helps with the migration strategy.

    But more fundamentally, the debate seems to be over classes as a programming tool mixed with a relational view of the data they manage. While we can and no doubt will continue to have divergent views of whether the mix is really advantageous, I would restate the argument that treating your data primarily as a relational object managed within a class is legitimate and in most business situations an advantageous over having to bridge the object-relational-mapping gap between the way the data is in most cases stored and how your programming logic deals with it. And designating a specific object such as a Business Entity to be responsible for all access to a specific set of data couples the data to the logic, though it remains true that the data can be extracted as a unit from the class that manages it. And much of the power of the language as a tool for manipulating data is well worth keeping and taking full advantage of, which is directly tied to viewing it as rows and fields within tables and not just as properties with getters and setters.

  • Why can't you just define the method in an interface?

    If there's no implementation of the method in the super class the implements the interface, the compiler will complain; so lacking true abstract methods, you currently have no choice but to put a 'dummy' implementation of the method into the super class and then put the meaningful implementation into the subclass.

  • I can't get very excited about writing code generators in ABL ... it is not one of the kinds of things that ABL is good at.

    I would agree, but there are at least two levels of tools we could be talking about here. What I was more immediately talking about is a fairly simple tool that can do substitution for basic information like or , as a simple replacement in a template source file. This is simple enough to do in ABL and can help you create a large part of the support skeleton for data definitions that come out of something like the OEA DataSet builder. Doing true application logic generation using an MDA is a whole different level of generation; heaven knows that effective tools have been built and are being built in ABL, but I would not argue that it's ideal for that purpose. There are initiatives going on within the community in the application generation area that we can all hope to be made more widely available -- that will not be for me to say or to undertake.

  • I don't think that one ends up needing to fight the language ... just decide what parts of it to use and how to use them. To be sure, there are some additional language elements which would be useful, but I think we have enough to do real work.

    In that code sample, I expect that the response will be that this is just preliminary stuff to illustrate the principles and that is why it has a message in it, but I agree with you that it would be a more acceptable example without stuff like that.

    An exception mechanism would certainly be nice ... and I mean one more like this http://www.oehive.org/ExceptionClass than what we have now.

    But, which said, I think one of the ironies of putting this stuff in the base component class instead of in the session manager per my technique is that it relies on the session manager getting started before any components or one gets an error that needs to be handled. If handled as a pseudo-singleton, it just starts the session manager if it isn't there already.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • In terms of context, I think we can distinguish three general cases of usage pattern:

    1) Use of individual entities, one at a time;

    2) Use of closely related entities, but which are often processed individually; and

    3) Use of groups of entities treated primarily as a set.

    The first corresponds to something like maintaining a customer record; the second to something like updating the order lines associated with an order; and the third to reporting, particularly on aggregate data.

    ...The third case might be argued in favor of wrapping a temp-table or PDS, but only if one can work out reasonable methods for accessing the properties of the elements.

    Maybe so, but I think the third case is the one that most often represents the work to be done in a business application. Given a relational structure (coming out of the database in any case) that represents -- whatever -- a customer and its multiple addresses and its contact information and its credit history -- the whole thing typically needs to be dealt with as a unit, not just as a collection of entities. This is what the PDS is all about as a complex relational data object. The first case of expressing what amounts to a single row as an object with properties and getters and setters is more manageable, but perhaps not the more typical use case. And of course the language traditionally provides a very effective way to access the properties of the elements: "IF table.fieldname = ..." True, the language does not enforce a restriction against cheating by accessing a table or field outside of the class that has been defined to manage the data, but that has to be a part of the development discipline that underlies any implementation of an application architecture.

  • What is the functional difference between a

    non-persistent .p and a facade class that does its

    work in the constructor?

    Two remarks:

    1) even when you put all the logic in the

    constructor, you still instantiate a class instance.

    So after initialization, you have loaded a class

    instance and you need a new server call to delete the

    instance. A non-persistent procedure doesn't suffer

    from this issue, since you call the server, let the

    .p do it's work, the result is serialized and the

    server is released for new requests.

    Well, of course, you can end the constructor in the procedure-turned-class with the statement DELETE OBJECT THIS-OBJECT, which makes the class pretty much identical in its behavior to a 'traditional' .p (with no internal entry points) -- but what's the advantage of expressing it as a class?

    2) you should use the constructor to initialize a

    class instance and leave it in a valid state. Real

    work should be done in a method called from the

    outside. When a class is complex to setup, you can

    refactor that code using an assembler pattern. A

    constructor with lots of logic is mostly an

    indication of a badly designed class.

    Agreed, so why can't things like this remain procedures?

  • This is not my opinion nor my preference. It's my question to John (PSC). What's the correct usage of OOABL, since ABL is a data centric and transactional language with its buffers, buffer scoping, temp-tables, etc. Is the OOABL suitable for creating (lots of) entity classes knowing the internal implementation of OOABL and missing a garbage collector?

    I hope no-one thinks it is up to me to supply the one true official answer to the question. I will only say that when I suggested in the presentation that the combination of procedural and class-based capabilities in the language -- even as it stands today, with some desirable features still lacking -- is an advantage rather than a workaround for serious defects, I was quite serious (Theo's derision posted later in this thread notwithstanding). Other languages are moving in the direction of supporting better relational data access in otherwise object-oriented languages, and we think they've got some catching up to do. I don't think that being wholly or purely object-oriented is going to be a primary concern to most developers of business applications.