Why move to OO? - Forum - OpenEdge Development - Progress Community
 Forum

Why move to OO?

  • I have a simple question: why move to OO? What are the specific benefits of OO programming over traditional procedural code? Specific examples and metrics would help. Also, we don't have much in-house knowledge or experience with OO so any thoughts around the investment/costs required to get up to speed with OO would also be helpful. I need to justify to others - both technical and management - that the benefits of moving to OO outweigh the costs.

  • I have a simple question: why move to OO? What are

    the specific benefits of OO programming over

    traditional procedural code?

    First, don't think of the new OO language features as necessarily something to 'move to' if that means rewriting existing procedures or a wholesale rearchitecture of coding styles. Also, I don't think you need to be steeped in OO theory to understand and take advantage of what these new features can provide as very tangible benefits. Think of them as extensions to the language like any others that you should consider using where they're valuable. That said, here are a couple of basic things the OO support provides.

    -- True inheritance. We all understand that often you have a whole bunch of procedures that all need to have the same basic capabilities but then modify or extend them for different data or different situations. The language has provided support for super procedures as a way to get some of this with procedures. Super procedures have various limitations, including the fact that the super procedure chain is established entirely at runtime, so there's no compile-time understanding of what is going to happen when the stack is put together. Classes allow DEFINITIONAL support for inheritance, so the compiler can understand and verify what the inherited behavior is and how it is extended, and do a lot more validity checking for you.

    -- Strong typing. In good old 4GL, a handle is a handle is a handle. This is useful for various kinds of very dynamic programming, but it means that the compiler has no idea whether what a handle holds at runtime will be valid. When you code RUN soandso IN hOtherProc, nobody knows whether soandso will in fact exist in whatever hOtherProc points to at runtime. In this and many other ways, much error checking is postponed until runtime. With classes, every variable that holds a reference to an instance of a class must name in its definition what type the other class is, and the compiler AT COMPILE TIME verifies that whatever public data and methods you reference are correct, by actually inspecting and compiling if necessary other classes that are referenced. This is a fundamental change from the procedure world, where no cross-checking is done, and moves a lot of error detection to compilation rather than the testing / tech support phase.

    -- Interfaces as contracts. An INTERFACE is simply a dummy class that names (with signatures) methods that other classes must implement (i.e, have code for) if they say they implement that interface. This is a way of getting the compiler to verify for you that if you have a whole bunch of classes that all do the same kind of job for different data or in different ways, that the methods you expect to be able to run uniformly in any one of those classes will be there and will have the right signature. So again, it moves more of the checking to compile time and increases reliability of your code when the pieces are put together.

    -- PUBLIC and PROTECTED methods and data. You can now define data members (variables and so on) as well as methods as PUBLIC, so you can define what data others (procedures or classes) can access and what methods they can run. PROTECTED means that others in the same inheritance stack can have access, but not the general public. This helps scope access to data and code flexibly. Support for properties of a class, which can have supporting code attached, is also coming.

    Those are a few of the highlights. You can intermix classes and procedures freely. Procedures can create instances of classes and run methods in them. Classes can RUN traditional procedures. So the useful features are available when you want to make use of them without forcing you to rearchitect what you already have.

    Enough for one message. Hope this is a useful start. There has been tremendous interest in the OO features in the community (at Exchange and PTW, e.g.) It would be interesting to hear what others see as the key points of interest and use cases.

  • While John's reasons are all good ones, let me give you two reasons from a somewhat different orientation.

    Consider that, over the last 10 years, programming methods in ABL and to some extent the language (prior to 10.1A) have been trending heavily in the direction of imitating OO ... doesn't that suggest to you that, now that we have real OO, one probably wants to stop pretending and start doing?

    PSC's advocacy of OERA and SOA puts them smack dab in the middle, possibly even in the forefront, of modern ideals of application architecture. This is a good thing. SOA has a very natural affinity to OO. Why fight it?

    While modeling has been around for years, it seems to be finally catching on in a much broader way that it ever has, especially in Europe, apparently. One of the reasons for this enthusism may be UML 2.0, which allows one to model an application much more completely than was previously possible, even to the extent of being able to consder the possibility of 100% generation of code from the model, although we are certainly not there yet with ABL (but I'm working on it). UML modeling is inherently OO. Again, why not do the natural thing? The fit will be better.

    I think there is a certain "fear" in many ABL shops about the difficulty of mastering OO. There is some justification for this fear since a lot of people who are writing in OO languages don't really "get it". I was in an OOAD class 10+ years ago and most of the people in the class had a couple of years of OO development experience at least, some a lot more. But, really there were only 2 of 35 or so that really "got it" at an analysis and design level. But then, I think that is true of any programming paradigm and the real level of mastery of architecture.

    But, the other side of this is that analysis to create an SOA is really no different than the analysis required for OO. Yes, that is the hard part, but once you have figured out how to think in terms of services, then mapping that to the language elements is not a difficult issue. This is no different really than it was learning to make good use of superprocedures. The idea is hard; the implementation is straightforward.

    To me, this is exactly the kind of situation where mentoring is useful. I don't mean sending off three of your staff to take an OOABL class ... athough that might not hurt ... but rather having an on-going relationship with someone who does "get it". In the beginning, he or she might provide a lot of guidance, thinking over where you are now, where you want to go, developing plans, sketching out constructs, building some framework and models, but then after you are started benig someone where you can raise your hand and ask a question when you run into something that you aren't sure about. As time goes on, you need to ask fewer and fewer questions. It is like learning to ride a bike ... you start off with someone holding the bike and moving slowly; then you go a little faster and the helping hand is nearby when you start to wobble; eventually you are riding on your own and only occassionally asking advice on how to do some new thing.

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

  • Consider that, over the last 10 years, programming

    methods in ABL and to some extent the language (prior

    to 10.1A) have been trending heavily in the direction

    of imitating OO ... doesn't that suggest to you that,

    now that we have real OO, one probably wants to stop

    pretending and start doing?

    Well, we never pretended OO. Big systems are up and running developed using "old" traditional procedural techniques.

    I think there is a certain "fear" in many ABL shops

    about the difficulty of mastering OO.

    Yes.

    To me, this is exactly the kind of situation where

    mentoring is useful. I don't mean sending off three

    of your staff to take an OOABL class ... athough that

    might not hurt ... but rather having an on-going

    relationship with someone who does "get it".

    What can we do until we find a mentor that does "get it"?

    Where to start?

    Any good OO literature or web-sites worth taking a look at?

    Regards.

  • Well, we never pretended OO. Big systems are up and running developed using "old" traditional procedural techniques.

    I've got 1.75MLOC of my own application which I could say the same about and no funding to modernize it. Fortunately, it is no longer being sold and I am focusing on new areas, so I don't need to move it forward.

    Which noted, if it is up and running and you don't have issues, then obviously you don't have any reason to rewrite the whole thing just to make it OO. I don't think anyone would suggest that. But, there are a lot of times when things aren't that simple and stable and that's when you need to start asking the question. As John says, it isn't as if you need to dump everything and start again. The two approaches can live side by side with a little planning. So, with a large existing application, you should be thinking more about OO when:

    • You need to add a new application;

    • A piece of the application needs a major overhaul;

    • You decide to convert a part of the application into a service as the first step in a gradual transition to SOA;

    • You need to interface your application with supply chain or other services;

    • You decide that it really is time to leave ChUI behind;

    i.e., any time you are doing something big enough that it isn't a patch and there is an opportunity to move some part of the application forward to a more modern architecture. For an ISV, this might be driven by declining sales. For an end user it might be driven by a need for new systems or new integration.

    The benefits of SOA/ESB ... and consequently of OO as not just development time issues, but they are also total cost of ownership issues. By moving to SOA, the business can become more nimble and responsive to changing business conditions and can explore new business opportunities. By not moving in that direction there may not be an out of pocket cost, but there is a lost opportunity cost.

    What can we do until we find a mentor that does "get it"?

    Well, you might try looking around PSDN, PEG, and OE Hive to see who is talking about and publishing material on OO. You just might find someone who offers this sort of service ...

    Any good OO literature or web-sites worth taking a look at?

    Specific to OOABL, I would look at http://oehive.org . There isn't a lot yet, but I have reason to believe that there will be more coming and it is all specific to ABL.

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

  • Thanks. I appreciate these detailed responses. However, they really don't provide much in the way of justification to move to OO. Will OO make our developers more productive? Is OO code more robust and less costly to maintain? Will OO provide better performance? I understand that some of the benefits of OO maybe be less immediate but it's a hard sell especially when there are short-term costs, ie. upgrade technology, lost productivity during transition, investment in training, etc.

  • Well, as they say, it's not a silver bullet. But, it also isn't as if you need to dump everything you have done and start over, either. If you are starting a new project, there probably will be some up front added cost in the learning curve, but your result will be better code reuse, better encapsulation, fewer runtime errors, and generally a cleaner application structure to serve as a foundation for the inevitable modifications. Plus, if you are moving to SOA, you will reap the benefit of the more natural relationship between objects and services. This won't be a big WOW, like the one that might get from moving to a 4GL, but over time it will get better and better.

    If you have a large existing application, then chances are you are going to have to continue to use a lot of your existing techniques because any one isolated modification won't be large enough to justify reinventinig that piece in OO (or anything else). But, if you have a piece you need to convert to a service or a new module or a module that needs a major rewrite anyway, then you can switch for that piece.

    Alongside that, you can remain alert for opportunities. E.g., suppose that your application has a lot of system level shared variables for passing context information. You know it is ugly, but you can't justify a stem to stern rewrite. Instead, you create a context object and wire it in so that it is parallel to the shared variables, i.e., you can get the same info from either. Then, as you work on various parts of the code, rip out the shared variables in that piece and substitute the object. Gradually, you will add beauty and maintainability.

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

  • The benefits of object-oriented programming cannot be easily quantified although some people have (unsuccessfully) attempted it. oo has advantages and disadvantages just like any other software design approach.

    I see the main advantages of the oo features of the 4GL as:

    0) Allows for much better modularity than before, with less work involved.

    1) The ability to have separate interface definitions, implementations, and subsequent usage of those interfaces makes it easier to correctly use the objects you create.

    2) Good ability to encapsulate functionality and data in objects, making for fewer dependencies between implementation and use.

    But as the others point out, reimplementing something you already have over again just to be using the latest stuff is rarely worth the effort. With a little practice (and programming /does/ require practice, just as many other things do) the oo4gl features can be useful for now things you may write. I've always found that reading other people's code is useful. More people should do it.

    I've thought about writing a paper called "Inheritance considered harmful". Inheritance must be used with care because deep class hierarchies will perform poorly, be difficult to understand, and can be difficult to change.

    I disagree vehemently with the good Dr. Hursh when he says SOA and oo have affinity. SOA is all about /modularity/ and architecture and language independent interface standards. That has nothing to do with objects per se, which can of course be used, but are not central to the ideas of SOA, and not required.

    -gus

  • By SOA and OO affinity, I mean that the structural units of SOA are well expressed in objects and that there are strong parallels in the kind of analysis and design necessary to partition an application into service and the analysis and desgn necessary to partion the application into objects.

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

  • I've got 1.75MLOC of my own application which I could

    say the same about and no funding to modernize it.

    Fortunately, it is no longer being sold and I am

    focusing on new areas, so I don't need to move it

    forward.

    ...

    there are a lot of times when things aren't that simple and stable and that's

    when you need to start asking the question

    Interesting point. Why do you feel that OO is an answer for the 2nd point and not for the first point? Architecural changes are always hard to sell: you can't demo what's under the cover, you can demo new screens.

    By moving to SOA, the business can become more nimble and responsive to

    changing business conditions and can explore new business opportunities.

    You can always write a facade around your old, procedural and perhaps monolithic application. It might be expensive, but it's less expensive than a restart. You can reshape your application from the inside-out, but SOA is about the other way around in my opinion.

  • 2) Good ability to encapsulate functionality and data

    in objects, making for fewer dependencies between

    implementation and use.

    The question is: can you achieve this goal in the ABL? Sure, you can hide attributes , but when it comes to shielding temp-tables and buffers in a typical ABL-application, it might get harder. You basically exchange the data from one class instance to another, via the exposure of buffers. Since there is no notion of a "record"-, "row-" or "tuple-" instance within a buffer, there is just a current buffer pointer, you break the encapsulation rule: data is seperated from the logic.

    I've thought about writing a paper called

    "Inheritance considered harmful". Inheritance must be

    used with care because deep class hierarchies will

    perform poorly, be difficult to understand, and can

    be difficult to change.

    Exactly! Often you can move responsibility to another class...

  • Well, as they say, it's not a silver bullet. But, it

    also isn't as if you need to dump everything you have

    done and start over, either. If you are starting a

    new project, there probably will be some up front

    added cost in the learning curve, but your result

    will be better code reuse, better encapsulation,

    fewer runtime errors, and generally a cleaner

    application structure to serve as a foundation for

    the inevitable modifications. Plus, if you are

    moving to SOA, you will reap the benefit of the more

    natural relationship between objects and services.

    This won't be a big WOW, like the one that might get

    from moving to a 4GL, but over time it will get

    better and better.

    Thanks Thomas. To Gus also. These details were a little more like what I was looking for. It would be nice if there was some more concrete economic data available somewhere.

  • Interesting point. Why do you feel that OO is an answer for the 2nd point and not for the first point?

    Do you mean why do I see OO as having a major role when one needs something new or significantly changed and not so major when there is an existing body of code and no driver for change? If so, it isn't so much a question of the utility of OO as it is the justification for doing anything substantially different. If there is little justification for change, then there is little justification for any kind of change, not just OO ... although it is possible to dip into from time to time. If there is justification for making change or something new, then the field is open and I think OO should bubble to the top.

    Architecural changes are always hard to sell: you can't demo what's under the cover, you can demo new screens.

    Depends on whom you are trying to sell. If you have an existing body of code that has four slightly different versions of the same logic in four different sub-applications, causing a maintenance nightmare every time there is a need for change, then one has a perfect argument for creating a service, no demo involved.

    You can always write a facade around your old, procedural and perhaps monolithic application. It might be expensive, but it's less expensive than a restart.

    Maybe, maybe not, especially if one considers total cost of ownership, not just the one time conversion costs. Create a kludge; create a maintenance nightmare.

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

  • The question is: can you achieve this goal in the ABL?

    Yes. Among other things, one can have a temp-table of objects. See http://oehive.org/CollectionClasses

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

  • It would be nice if there was some more concrete economic data available somewhere.

    Wouldn't it though! The real problem is, YMMV. Twenty years ago I read a study on programmer productivity which found top to bottom differences of 1000 to 1 with language, tools, and experience each contributing about a factor of 10. I suspect the range is wider now. So, it is very easy, for example, for a good tools environment to swamp out the productivity difference of a different programming model. But, that doesn't mean that the different programming model can't contribute its own differential.

    Not to mention needing to look at things over time. Looking at the very first project and the development phase only might show a negative impact from the learning curve, but once past that initial learning, code reuse, stablity, lower maintenance, etc. start to kick in.

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