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

Trying to find an "in" to OO

  • guilmori wrote:

    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

    Such as expectation is unrealistic.  Every ORM implementation must deal with relational structures at some point. That's why they're referred to as Object-Relational Mapping. The PDS in M-S-E is a private internal relational structure which is completely encapsulated. This and every other class in the pattern is fully OO-adherent.

    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.

    Sticking with PABLO while conceding that its performance is unacceptable when there is a significantly better performing, OO-adherent alternative is your choice. But then you must accept the adverse consequences of that choice.

  • pmagnay wrote:

    Every ORM implementation must deal with relational structures at some point. That's why they're referred to as Object-Relational Mapping.

    I completely agree with this, but I think the ORM is best to be isolated in the data access layer, where the 4GL nature of ABL (compile time access to datasource & ProDataSet) really shines.

    Business layer should focus on a pure OO model, which is better in my opinion to model complex business logic and prevent its complexity to enter the code.

    The PDS in M-S-E is a private internal relational structure which is completely encapsulated.

    Yes, but it reside in the business layer... So you have another mapping to do to transform PDS records into class instances, no ?

    Anyway, I may be arguing with very foggy glasses, since I don't know all the details. I'll continue to wait.

  • guilmori wrote:

    I completely agree with this, but I think the ORM is best to be isolated in the data access layer, where the 4GL nature of ABL (compile time access to datasource & ProDataSet) really shines.

    Business layer should focus on a pure OO model, which is better in my opinion to model complex business logic and prevent its complexity to enter the code.

    The PDS in M-S-E is a private internal relational structure which is completely encapsulated.

    Yes, but it reside in the business layer... So you have another mapping to do to transform PDS records into class instances, no ?

    Anyway, I may be arguing with very foggy glasses, since I don't know all the details. I'll continue to wait.

    You either accept the principle of encapsulation. Or you do not.  The private internal data structure of a class is not any other class's business.

    Hardly justification for choosing the PABLO approach which you clearly conceded has unacceptable performance.

  • Reasonable people can differ about what they consider good OO.  Phil and I disagree on a number of points.  The CloudPoint M-S-E pattern is clearly a very thoroughly thought through pattern and should be looked at closely by anyone who is considering a PDS-based solution.  But, I do feel that there are aspects of it which are bothersome if one is trying to adhere strongly to OO principles.  For starters, having a business entity which encapsulates behavior, but derives its data from another object is disturbing given the basic expectation that entity objects will encapsulate both data and behavior.  The BE *appears* to hold the data from the perspective of a client object, which is good, but the data is actually somewhere else.  There are other issues I will cover in my full review.  They may or may not concern you.  There is certainly a lot about M-S-E which is interesting and well-considered.

    On the other hand, putting aside the fact that simply adopting PABLO  does not necessarily mean adherence to OO principles

    Of course not.  Neither does using M-S-E.  Within the M-S-E pattern there are clearly choices one can make and those choise can be either better or worse according to one's own OO principles.  We have established that we don't agree on all of those choices and others will have to make their own choices.

    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.

    If such test data exists, I would very, very strongly encourage you to publish it so that we can evaluate the test., both to determine whether or not it represents the actual pattern one proposes to use and so we can evaluate whether the difference is meaningful. I can readily think of several versions of how such a test might be done which would tend in this direction, but I can also think of other versions where I don't currently expect it.  I will eventually be doing some of my own testing, but if you've already done some, let's bootstrap the process and get the info out there.

    I don't know if most readers are aware that there is much in good OO practice which negatively impacts performance.  E.g., working to loosely couple two subsystems or layers is likely to produce an interface that is less efficient that, for example, passing something structured like a temp-table.  But, loose coupling is good for maintenance, so there is a trade-off choice to make.

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

  • I have a whole family of "approaches" which might all be described as PABLO, some of which I would expect to perform less well than others, so it is important to clarify what is being tested.

    I, and I expect others, would be very interested also in hearing your explanations for a 50X differerence.  Take, for example, a task like reading an order and its lines from the database and repricing the lines using a new discount structure.  However this task is broken into layers and packaged, at some point in the process one is going to create one BE per line, execute a method, persist the data, and delete the objects.  The same amount of data will get read from the database.  The same number of BEs will get created (assuming M-S-E as the exemplar for the PDS version) and deleted.  The same methods will get run.  The same data will get persisted.  So, where exactly in the cycle does one get a 50X penalty or advantage?  Now, if you use a one line TT in every BE as some have suggested in order to take advantage of the serialization methods, then I can see that creating all those TTs would have a big performance impact.  But that isn't my idea of a PABLO.

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

  • I order to know what needs fixing and whether or not it needs fixing, we need to know where the performance hit is.  If there really is a 50X difference, that strongly suggests that something is wrong and needs fixing ... even if you feel that you have managed to program around it.

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

  • Every ORM implementation must deal with relational structures at some  point.

    Every OO application which strores its data in a RDBMS has to deal with ORM, but every other OO language does so deep in the data layer.  M-S-E is persisting the relational model deeply into the business logic layer.  No matter how much you wrap that to make it appear like objects from the outside, it is not something that one would do in any other OO language.That you have made it work well for you, doesn't mean that everyone else should have to make the same choice.

    This and every other class in the pattern is fully OO-adherent.

    We know that you believe this, Phil, and I respect the strength of your convictions, but not everyone else sees things the same way you do, as evidenced by the difference in your and my view of Decorator.  Surely, it isn't hard to understand that someone might find the idea of an intensely relational structure firmly emplanted in and core to the functioning of the BL layer is a disturbing idea from a traditional OO perspective.  Likewise, the idea of a "collectioni" which contains nothing and whose key implementation is in another object is not exactly traditional OO thinking, no matter how much it behaves like a traditional OO collection from the outside.  There needs to be room for other versions of "right", especially since only a tiny bit of M-S-E has been exposed to the public.

    Imagine, if you will, one of the authors of AutoEdge singing the praises of what a wonderful exemplar of OERA it was, but the only thing published was one UML diagram and a few discussions ... no download and documentation in which we can judge for ourselves how good or bad an exemplar it is.

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

  • tamhas wrote:

    This and every other class in the pattern is fully OO-adherent.

    We know that you believe this, Phil, and I respect the strength of your convictions, but not everyone else sees things the same way you do, as evidenced by the difference in your and my view of Decorator.  Surely, it isn't hard to understand that someone might find the idea of an intensely relational structure firmly emplanted in and core to the functioning of the BL layer is a disturbing idea from a traditional OO perspective.  Likewise, the idea of a "collectioni" which contains nothing and whose key implementation is in another object is not exactly traditional OO thinking, no matter how much it behaves like a traditional OO collection from the outside.  There needs to be room for other versions of "right", especially since only a tiny bit of M-S-E has been exposed to the public.

    Never have I claimed to have the one right approach. But not once (after countless requests) have you indicated a single OO principle that M-S-E is violating. Yet you continue to characterize it as not following OO and on the other hand claim that PABLO is. No matter how many times you repeat something, it doesn't make it true. 

    You are entitled to your opinions but people are also entitled to know why you need to portray every other solution except yours as somehow lacking in OO.

  • Sticking with PABLO while conceding that its performance is unacceptable  when there is a significantly better performing, OO-adherent  alternative is your choice. But then you must accept the adverse  consequences of that choice.

    We may be stuck with the adverse consequences, but there is no reason to accept it as necessary.  For starters, we need to know what it is that produces that difference.  There might be lots of other ways to solve the problem which would be more aesthetically pleasing to some of us.

    The real key issue here is understanding where the performance hit is coming from, whether or not it is understandable, and whether or not there are any reasonable alternatives.  Think of the problem Tim Kuehn was having with too many temp-tables.  Once that problem got properly exposed, two things became apparent.  One was that the immediate cause of the problem was a result of the way in which TTs were used in the application, something unlikely to be experienced by most other people and something for which there were not only alternatives, but one could argue the alternatives were a better design.  The second was that options were revealed by which substantial tuning could occur which dramatically improved the situation.

    We need a similar discovery process here.  50X is simply not reasonable given that one is basically creating the same number of objects with the same amount of data.  Where is the performance difference coming from then?

    E.g., if it were unusally expensive to create an object, I can see that a PDS approach which simply operated directly on the lines of the PDS might be a lot faster than one that needed to create and delete an object for every line.  Were that the case, then I would say that PSC hadn't actually yet given us an effective OO implentation.  But, that can't be the case with M-S-E because you are creating the same number of line objects.  So, where is the hit?

    Note that I can imagine there is a performance issue with an application which needs a large number of collections since right now that implies a large number of TTs, if one is going to have a real collection and not a pointer.  That might create a good argument for enabling PLO fields in work-tables to lessen the overhead when the collection was a simple one.  That is something we can understand, test, and lobby for.

    Simply claiming M-S-E is 50X faster than PABLO isn't sufficient.

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

  • It's what we found.  Apparently Guillaume also found it unacceptable.  So have others.

    Perhaps you could send me your PABLO solution and we'll redo the testing on it.

  • You either accept the principle of encapsulation. Or you do not.  The  private internal data structure of a class is not any other class's  business.

    Encapsulation is a appropriate property of an OO solution.  It does not, however, justify putting anything you want inside an object and deciding that it is OK because it is encapsulated.  E.g., it clearly would not be good OO to put direct database reads inside an object in the BL no matter how invisible that read was to anything outside the object.

    Conversely, one can't help but observe that an M-S-E BE does *not* encapsulate the data and behavior of a BE as one would expect it to from traditional OO design, but rather the data remains in the Model.  You make it appear that the data is in the BE to any client of the BE, which is good, but the data isn't really there.

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

  • Never have I claimed to have the one right approach. But not once (after  countless requests) have you indicated a single OO principle that M-S-E  is violating. Yet you continue to characterize it as not following OO  and on the other hand claim that PABLO is. No matter how many times you  repeat something, it doesn't make it true. 

    I am sorry that it is taking me so long to publish my analysis.  It seems pretty clear, however, that when I do, you are unlikely to agree with it and so I am not sure that the situation will have changed much.  This seems evident by our continuing disagreement over what the GoF Decorator pattern is supposed to be used for, regardless of any question of the use of that pattern or construct in M-S-E.  I have, in fact, made some of my points in this very discussion including the relational structure in the BL, the data not being in the BE, and the core implementation of the ES being in the model instead of the ES.  I believe I have previously remarked on the lack of normalization in the use of Model accessors in the pre-10.2B implementation, which you have now improved.  At this point, I don't expect you to agree with any of these points.  That doesn't make it wrong for me to point them out.

    For other people, one of the biggest problems is that they have next to no information on M-S-E.  I only have a smidgen because of our off list discussions.  I will be trying to document that for other when I can get to my whitepapers, but really, if M-S-E is to be held up as an exemplar for how to do OO in ABL effectively, it needs to get documented and disseminated.  How is Guillaume, for example, to know whether he likes it or not.  All he has is one UML diagram, two threads on PSDN, and your assertion that it is OO squeaky clean and 50X faster.  That is a lot to swallow without more details.

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

  • Without so much as a description of the test, how would I send you anything?

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

  • tamhas wrote:

    Without so much as a description of the test, how would I send you anything?

    Let's start with something simple. Just send your current PABLO BE implementations for Customer (inc/ 2 or more sub-classes), Order (inc/ 2 or more sub-classes), and OrderLine (inc/ 2 or more sub-classes) that map to the tables of the same name in the sports2000 database.

    The test that will be re-run using your implementations (instead of ours) will consist of

    1) Processing all the 1122 BEs corresponding to records in the Customer table.

    2) For every existing Order BE associated with each Customer BE, a new OrderLine BE will be added (random item, qty, discount), an existing OrderLine BE will have an additional 5% discount added and extended price recalcuated, another existing OrderLine BE will be deleted.

    3) For every Customer BE, a new Order BE (random subclass) will be created with 3 OrderLines BE (different sub-classes, random item, qty, discount).

    4) Each Customer BE will have have Balance updated according to the changes in the Order and OrderLine data.

    5) All changes to the BEs to be persisted in the database.

    When can you send this out?

  • There are quite a few things unspecified here.

    What is the basis for the subclasses in each case?  I haven't looked at the sports2000 schema in a long time, since it is so painfully simplistic, but presumably to be any kind of reasonable test, we should be using the same subtyping model.

    Second, it isn't actually very meaningful for me to send you just BEs.  At a minimum I am going to have to build data access components, a messaging system, a BL factory for instantiating the BEs, and a client to do the processing.  At last count I think I had 11 different ideas about how to do the messaging, so I have a fair amount of experimenting to do before I am ready to publish.  I'm also going to need a few more details.

    I also have some questions about the test.

    It seems as if this is a test in which a relatively large number of BEs are created that are not accessed or used in any way.  This, of course, could have performance implications and could be an indicator for a lazy load pattern.  Did you try that in your testing?

    I presume that you are using sports because it is ubiquitous, but I have a problem about tests based on sports because they can't possibly reflect what happens in real applications.  I have been working on building some models corresponding to the kind of complexity represented in my Integrity/Solutions application and they are just massively more complex than anything one could do in sports.

    Likewise, I would assume that you are doing all orders for all customers in order to create a substantial body of work so there is a meaningful volume to measure, but as a result the test is about something that doesn't correspond to what happens in real world applications, at least not typically.  In particular, I would say that typical operational patterns were more about reading an order and doing a bunch of work on it and then putting it back rather than reading large numbers of orders and doing a very small amount of work on each one.  Yes, it happens, but it isn't typical of day to day performance.

    In particular, were you to create a PDS with customers, orders, and lines all in the same dataset, fill that from the database in a single operation, and then process on that data set, I would expect that to be significantly more efficient than creating a separate object for everything, most of which receive no processing and even the few which do receive very little.  I would expect, for example, that if I created a data layer which had the same comprehensive PDS and filled that in a single operation and then built the BEs from that, it would be more performant than separate reads for every BE.  That is a data layer optimization which one decide to include in an application if there are sufficiently frequent contexts for doing such a mass update.  The combination of a single FILL for the PDS in the DL and lazy load for instantiation of BEs which were actually going to be processed is likely to have a big impact.

    Conversely, if the typical application task was a single order, its lines, and something about the associated customer, i.e., one line in both the top two tables of the PDS, then the PDS is a rather heavy solution for something which is only going to take a handful of objects to represent.

    So, not only is this not a question of my just whipping up a couple of classes, but I have some fairly significant questions about the significance of the test.

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