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?

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.

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.

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.

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.

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.

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

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.

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

No, that's not what I meant. You said that it was no option for your own code, but it might be an option for someone else's code. A question that popped up: when did you decide to ignore the 1.75 million lines of code? I mean, there are lots of AP in the same situation and it's very hard labour to re-architecture an old client/server or host-based application.

I have a simple question: why move to OO?

...

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.

You might want to consider to OO very specific parts of your application. This way you isolate the OO-parts from the main stream development in your office and it allows you to create OO-expertise in a small group.

Two examples:

- when you're using a super-procedure stack, you might want to redesign it using a more natural and robust OOABL implementation.

- when you work with interfaces, you can introduce flexibility in your application. It allows you to create pluggable components. When you define an authenticator interface, you can deploy it with a configurable authenticator implementation. You can build an authenticator against your database table or against active directory. For your application it doesn't matter, since it talks to a known interface. The end-use can configure the way it wants to work.

I am ignoring my existing code for now because it would take investment capital I don't have to do the work modernizing it, documenting it, and selling it. I certainly will be experimenting with it in my work on transformation, but right now it seems unlikely that I will ever modernize the whole thing. I would love to, but with only one remaining customer, there is no justification.

I agree, it would be nice if there were some economic data available. I think the reason such data is hard to come by is that there aren't any significant economic benefits to using oo as compared to not doing so. However, that does not mean there are no benefits. OO, used with care, can be a nice way to build software. It's just not the solution to all problems.

The software development world has been striving for reuse for more than 40 years with little success. During that time, all sorts of things have been touted as the silver bullet that will finally enable it. Recently I've seen articles that claim SOA will solve the problem. It won't.

Achieving reuse is (mostly) not a technology problem but a cultural one. Designing modules that can be used again later is very hard to do on a large scale. We do have some large scale reusable software though: operating systems, language libraries, and so on. Each has taken many years to develop. In most projects, there are no incentives for using or producing reusable modules and lots of reasons not to do so. People often talk about a piece of software in terms of the number of lines of code (while agreeing it is a meaningless measure) but rarely about how many existing modules were reused or how many new reusable modules were produced.

-gus

While it is certainly the practical reality that:

1) One can create a mess in any language; and

2) Achieving good structure and re-use is difficult in any language,

I don't think that this means that the choice of language and architecture is irrelevant.

Lack of re-use in procedural model ABL is mostly an issue of culture, but there is little in the language to create a dissonance which might drive one toward re-use ... achieving re-use requires imposition of strong discipline. In OOABL I think there is language reinforcement of the notion that re-use is right ... e.g., in a procedural model, there is nothing in the language or historical culture that suggests that one shouldn't write a unique piece of code for updating the customer credit status which was separate from the rest of the customer update code, but in an OO world one knows that everything that updates the customer should be in one place. This still requires discipline, but there is more of a "hint" from the language and history associated with OO that one should be doing it that way.

Plus, I think there is an opportunity because of the strangeness of OO in most ABL shops. Because it is new, there will be an expectation of doing things differently, an expectation of new disciplines being required. This gives one the opportunity to impose new disciplines more easily than trying to "reform" programmers working in the same old paradigm they have been working in for years.

Perhaps that in itself is one of the benefits of moving to OO ... the expectation of a new culture.