Interesting point. Why do you feel that OO is ananswer for the 2nd point and not for the first point?Do you mean why do I see OO as having a major role
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-houseknowledge or experience with OO so any thoughtsaround the investment/costs required to get up tospeed with OO would also be helpful.
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.
- 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.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
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.
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.