Trying to find an "in" to OO - Forum - OpenEdge Development - Progress Community
 Forum

Trying to find an "in" to OO

  • I come from a background of OO programming.  I started with Java and more recently I've done some iPhone stuff with objective-C.

    However, I'm the only one in our dev team who has used OO programming before.  One or two other people have seen it and some have a rough idea of how it works.

    I've been trying to think of some way to apply OO principles to an area of our software that I can explain to people and they'll like it.  Whenever I have tried in the past the examples haven't been very good and people have said "Yes, but we can already do that" etc...

    I came up with an idea today when trying to sift through a single report that doesn't return the right data.  It spanned over 7 .p files and well over 20 include files.  It got to the point where I could no longer follow the logic of the code and decided that on monday I'm going to rewrite it in one file and with a fraction of the code.  Upon starting to try and fix it I was even warned by my colleagues not to bother too much as this particular report is "beyond repair".

    This is the second time this has happened to me this week and I've just had to "give up" with trying to fix something and start again from scratch.

    Anyway, my idea was to find an OOP way of creating reports.  The problem I have is I don't know too much about what is possible with OpenEdge.

    The rough idea of my class model is this...

    Abstract class 1. Communication - contains methods for emailng, sending to printers, saving to files, etc...

    Class 1. XMLDocument - contains a string (or something more suitable) that contains XML code.  Also contains methods for adding elements and formatting etc... that redirect to our SAX writer.

    Class 2. Report - implements Communication class and contains its own XMLDocument class.  Maybe some methods to do some extra report type stuff.

    Class 3. ItemReport - is a child of Report.  Contains a method for getting the item data and adding it as elements to its XMLDocument object.

    Class 4. CustomerReport - again is a child of Report.  Contains method for getting relevant customer data and adding it to its XMLDocument object.

    By using this we can quite easily change our XML writer or email settings or temp folder etc... just by changing the parent folders.  We could even create a method for Report that logs the report creation to a file each time it runs.  The biggest selling point would be not having to recompile everything once this is done.

    Is this kind of model possible with OpenEdge?

    Am I thinking about it in completely the wrong way?

    Any tips are welcome!

    BTW, I've got the gsoop.pdf document and I'm going to have a skim of it this weekend

    Thanks!

  • Am I thinking about it in completely the wrong way?

    Possibly, but we don't necessarily have enough information.

    I confess that I haven't thought a lot about OO and reporting since I mostly moved to using third party reporting tools a number of years ago, but ...

    I am curious about the idea of an abstract class for communication that is implemented by the report.  Isn't most of the communication standard packaged code that gets/got written once and then is re-used?  If not, why not?

    I'm not sure what the role of the XML here?  Do you select the data for the report and then package it as XML and then send it off to various consumers?  If so, I would take a step back and note that the XML is a form of message data packet so it should be something produced from the internal representation, not *be* the internal representation.

    I'm not seeing any separation here of data, business logic, and presentation.

    The data layer should be reusing or creating reusable components for access to the data.  The business logic layer should be doing the work of creating the report and you should be thinking about possible re-usable components there.  The presentation layer should be taking the results of that work and packaging it for communication to the user.

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

  • The problem I am facing is that I am coming from "proper" OO languages and don't know how to relate my knowledge to what OE can do.

    My model was more of an example than a real data model as I just wanted to test the water as to what was possible.  I have never done any OO beyond small to medium sized programs and so I'm looking for somewhere to start where I can be familiar with what I'm working with.

    The program we have at the moment uses somewhere towards 1 million lines of code and things like reusability and sensibility are a distant dream at the moment.

    It is improving but it i still not ideal.

    How would OO typically be used in OE?

  • Let me try to clarify what I am trying to say.

    At the moment the software works through a UI on the client PC.

    The user presses a button or chooses a program or enters some info.

    This triggers an internal procedure in the program.

    Upon doing this the program will run a persistent procedure (or non-persistent in some newer cases) and get the info (or validate info, save info, etc...).

    Then the program will end the persistent procedure if needed.

    The UI then uses the info and displays it to the screen some how.

    That is the general model that 90% of the work in the program is done.

    The rest of the work is done producing reports.  The system uses the appserver to create a queue request with info about what the request is.  This is then picked up and run by a report queue.  The report queue then runs whichever procedure is requested with the relevant parameters.  Upon doing this you tend to get an unintelligible snake moving in and out of inumerable files until the temp tables have been produced and the files are written (or whatever) and the resulting file is either sent to a printer or emailed to a user as a csv or xml or pdf etc...

    I am trying to find somewhere in all of this that I can try to work out a way of getting some OOP in there.

    This is where I am struggling.

    I'm not intending on designing anything properly or starting any coding.  In fact I have no doubt that, when the time comes, we will be getting someone in to help with designing something.

    I'd just like to get my head around how OOP can be used.

  • How would OO typically be used in OE?

    I am inclined to answer that it would be used the same way in ABL as it is in any other language.  I have written a number of times that OO best practice in ABL might be different in some ways than OO best practice in a 3GL since ABL is, after all, a 4GL, but the more I consider the issue the more inclined I am to think that there isn't as much difference as some people would like to think.  To be sure, there ae some implementation differences. E.g., right now, the only apparent mechanism we have for implementing a collection or map class is a temp-table, which is a rather heavy-weight artifact compared to a Java collection class.  But, wrapped up in reusable generic code ( http://www.cintegrity.com/content/Collection-and-Map-Classes-OOABL ) it is going to get used pretty much the same way as a collection class is in Java and for the same reasons and in the same contexts.

    Now, there are some people who think that ABL's greatest virtue is the ease and power of handling relational data.  One can see why they would think that.  So, those people tend to think that one of the ways OOABL should be different is that we should preserve the relational structure of data in the business logic, typically in the form of a PDS.  See http://www.cintegrity.com/content/Patterns-Managing-Relational-Data-OOABL for some discussion of this and keep an eye out for my forthcoming whitepapers which will cover this in greater detail.  If you agree with this position, you will want to consider one of the models presented for the purpose, especially the Model-Set-Entity patterns which is discussed on this forum since it manages to present a very OO-like appearance of the business entities and entity sets, aka collections even though the underlying implementation uses a PDS.

    But, if you think that is not very OO-like ... and it isn't in a number of ways ... then you will want to think in terms of PABLOs, Plain ABL Objects and those should be pretty close to your OO experience.

    I should probably note that there is a lot of nominal OO in the world which isn't necessarily very good OO, not just from programmers fresh out of school with a couple of courses under their belt, but from big Authorities.  I was re-reading parts of Martin Fowler's book on Refactoring lately and I was struck, not only by the rather cavelier attitude about slapping something together and then fixing it as time allowed, but on the fact that his refactorings are never tied back to the underlying OO modeling of the problem space.  I .e., he talks about moving around data or methods in order to limit coupling or to simplify something complex ... all good stuff ... but never talks about noticing that the cohesiveness of an object is something that should be based on the cohesiveness of entities in the problem space.  I.e, if the problem space had been decomposed properly in the first place, the data and methods should have been in the right place from the start and the refactoring is just fixing the fact that this was not done.

    I do hope that you are saying that there is a million lines of code in the application and not in the one report!

    If you can get some interest from the company in the potential of OO as a way to improve your application going forward, I would suggest bringing in a consultant (hint, hint) to do a bit of orienting and help get you off the ground on the right foot.

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

  • Thanks!

    I think I'm definitely going to have to do some more reading.

    I'll def be following your link and having a good read.

  • The answer is, the samv, only different ...

    You can approach this from either end.  From the bottom, take the exisitng program(s) and start identifying self-contained, cohesive units of work.  Those are candidates for being turned into classes.  Move the logic for one into class form, change the calls, and you are back to a functional program again.  Do it again with another piece.  Each step should make the result easier to understand because each unit of functionality will be wrapped in a box where you can forget about how it does it and just pay attention to what it does.

    Or, start at the top.  Think how you would do it in Java or whatever (omitting the libraries you would have there, but will have to create here).  If you can write a good OO Java application, then the OOABL one won't be substantially different.

    Think in terms of the OERA layer separation.

    Think about what is good to do on the server versus what is good to do one the client.

    Slice up the functionality into coherent, cohesive units with minimal coupling.  Turn each unit into a class and hook them togehter.  Presto!

    Really, all of this is a good way to be thinking about .p structure too.  If you look at the patterns and principles white papers on my website, you should be able to think how to use most of the same ideas applied to .p code.

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

  • Attached is a class wrapper for the SAX writer. You might find it helpful with implementing 'class 1'.

    A small warning though, it's not completely tested.

    Cheers,

  • The problem I am facing is that I am coming from "proper" OO languages and don't know how to relate my knowledge to what OE can do.

    I would suggest using OOABL in the same way you've used other OO languages. There will certainly be stuff that's different (temp-tables etc), and some stuff that's missing or not working as you'd expect (and I'd ask you to report this to Tech Support), but it's still OO, and the fundamentals still apply. What's important is the application design, and less so the language in which it's implemented (if you look at Fowler's patterns online or even at coding concepts on Wikipedia, notice that they're all shown in more than one language).

    -- peter

  • tamhas wrote:

    Now, there are some people who think that ABL's greatest virtue is the ease and power of handling relational data.  One can see why they would think that.  So, those people tend to think that one of the ways OOABL should be different is that we should preserve the relational structure of data in the business logic, typically in the form of a PDS.  See http://www.cintegrity.com/content/Patterns-Managing-Relational-Data-OOABL for some discussion of this and keep an eye out for my forthcoming whitepapers which will cover this in greater detail.  If you agree with this position, you will want to consider one of the models presented for the purpose, especially the Model-Set-Entity patterns which is discussed on this forum since it manages to present a very OO-like appearance of the business entities and entity sets, aka collections even though the underlying implementation uses a PDS.

    But, if you think that is not very OO-like ... and it isn't in a number of ways ... then you will want to think in terms of PABLOs, Plain ABL Objects and those should be pretty close to your OO experience.

    The CloudPoint ORM (developed by Progress Professional Services) that utilizes the aforementioned MSE pattern is 100% adherent to SOLID OO principles. It's not just very OO-like - it is completely OO. It definitively demonstrates that one can leverage PDSs while adhering to generally accepted OO principles and practices (ie, SOLID).

    On the other hand, putting aside the fact that simply adopting PABLO does not necessarily mean adherence to OO principles, testing has shown that this approach is at the very least 50 times slower and 3 to 5 times more resource intensive than using a PDS approach.

    Phillip Magnay

    Senior Principal Architect, NA Professional Services

    Progress Software

  • Phil,

    On the other hand, putting aside the fact that simply adopting PABLO

    does not necessarily mean adherence to OO principles, testing has

    shown that this approach is at the very least 50 times slower and

    3 to 5 times more resource intensive than using a PDS approach.

    Can you clarify what "this approach" means? And is a "PDS approach" something like M-S-E? Or more traditional PDS-using-procedures?

    Thanks,

    -- peter

  • pmagnay wrote:


    On the other hand, putting aside the fact that simply adopting PABLO does not necessarily mean adherence to OO principles, testing has shown that this approach is at the very least 50 times slower and 3 to 5 times more resource intensive than using a

    PDS approach.

    Yes, that is the kind of unacceptable performance we are seeing.

    There is no performance problem in other OO language.

    When is this gonna be fixed ?

  • "This approach" means PABLO: where plain ABL objects are created and inserted into collections, and data from the database is moved into and out of these objects in those collections.

    By "PDS approach", I was referring to CloudPoint's ORM M-S-E, not non-OO PDS approaches. However, non-OO PDS approaches will also be at least 50 times faster than the PABLO approach.

    Phil

  • Everyone that I am aware of who has tried the PABLO approach has experienced the same unacceptable performance.

    As for supposedly "fixing" it, why is any such "fix" necessary?  As we have shown through developing M-S-E, PDSs can be utilized while remaining completely adherent to OO principles.

    Phil

  • pmagnay wrote:

    Everyone that I am aware of who has tried the PABLO approach has experienced the same unacceptable performance.

    As for supposedly "fixing" it, why is any such "fix" necessary?  As we have shown through developing M-S-E, PDSs can be utilized while remaining completely adherent to OO principles.

    Phil

    I am still eagerly waiting for the inners of the M-S-E, so I may be doing wrong assumption here.

    It seems to me that M-S-E adhere to OO principles, but only from the consumer point of view, ie: until we go into the private definition of the business model, which I think is using mainly relational concepts.

    Some say that since its private, it's not important how the data is stored in memory (PDS). But I do not agree.

    It is not a "do and forget" kind of class, there will be probably a lot of maintenace/improvement to be done inside these classes, and I don't like having to flip the switch OORelational all the time.

    Why can't we live in a full OO world

    But nonetheless, even if the M-S-E fix the performance problem, it is not a reason to discard the simplicity of PABLO approach, which is widely used in other OO language.