Layers, objects, and granularity
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 31 Oct 2008 14:52:45 +1300
I've been talking a fair bit lately about the things in the topic above.
This post is intended to provide some conceptual background as to why I
think they are important.
After nearly 10 years now, working with classes and objects in COBOL and
other languages, I can "distill" the experience into what follows...
LAYERS ("Tiers before bedtime...?"):
The idea of separating code into layers is fairly anathema to traditional
COBOL.
You get input, you process the input, you write the output. Where's the
problem?
Separating these functions just introduces overhead.
While that may have been true in the early days of COBOL, anyone who worked
on an IBM mainframe site will recall the impact that something like a new
release of the Operating System, data access software, or screen handling
caused. Review of all the code. Many man-days of lost programmer
productivity.
Transporting code to a different platform didn't happen that often, but when
it did, it was a nightmare. Many of the promised "platform independent"
features of COBOL failed to materialise because the screens or data storage
were proprietary.
Gradually we learned to "isolate" the actual functionality (Business rules)
from the input and output and replace them with an interface. CICS and
IMS/DC were both good examples of this: CICS used Basic Mapping Support
(BMS) to interface to a display screen, IMS/DC used Message Input
Description (MID), Message Output Description (MOD),Device Input Format
(DIF) and Device Output Format (DOF) buffers and commands to separate the
presentation functionality from the Business logic. The Business logic saw
only a buffer and was able to request attention identifiers (PFKs and ENTER)
and change screen attributes, if required. Other platforms used similar
interfaces to their presentation software.
By the time Client/Server processing arrived, these early intimations had
evolved into the "Three tier model". Three separate layers of design,
connected by interfaces. Presentation layer, Business layer, and Data access
layer. Instead of some business logic incorporating a READ or using ESQL
directly, it could request data through the interface (with PERFORM or
CALL). It simply used a buffer (or Global Working-Storage in COBOL's
case...) to process data and placed the results in another part of the same
interface.
Despite the "layer" imposing an overhead (compared to direct READ or FETCH)
it did mean that changes to Business logic had less impact overall. Much
duplication was eliminated. Furthermore, completely separate changes to the
actual Data Access layer (like an upgrade of the software, some physical
tuning, adding new stored procedures, or new tables on a database...) had no
impact on the existing Business logic.
By insulating Business logic from its presentation and data requirements,
there is much less trauma when change in one of these layers occurs.
OBJECTS:
Leaving aside the debate about OO programming versus Procedural programming,
why are objects important?
Some of the reason is touched on below in GRANULARITY, but the simple answer
is: Because they are small and independent.
If you can isolate a piece of Business logic and encapsulate it into
something that has its own defined attributes and behaviours, that
communicates with the rest of the world by a clearly defined interface, is
predictable and does exactly what it is specified to do, is not dependent on
or subject to variance in the rest of the environment, then you have
something of great value. Properly written classes (an "object" is an
instance of a class) can achieve this. If you can then place this class into
widely varying technical environments (like the desktop or the Web or your
cell phone or PDA) then you have a "component". Why are components
important? Because you can build things with them... :-)
GRANULARITY:
Granularity concerns the size of a unit used for construction.
One of the major problems which has beset COBOL right throughout its life
has been the cost of maintenance. Changing source code is labour intensive
and expensive.
Fairly early on in the piece (late '60s, early '70s) COBOL shops began to
realise that, while running a mainframe wasn't cheap, the major part of
their budgets was spent on programming for development and maintenance, and
maintenance cost MUCH more than development.
The problem comes down to granularity.
If the average size of a source program is 5000 lines (or even half that...)
and you need to change 10 lines, you don't have to be a statistician to see
that there are risks involved.
In effect. the fewer lines of code there are in the unit you are tinkering
with, the lower is the risk of getting it wrong, or perhaps even worse,
upsetting something else completely unrelated to what you are fixing. When
all data is Global (as it is in Working-Storage) and different logical
processes are sharing it, it would be surprising if everything went off
without a hitch. The more times you have to touch the code, the greater the
risk...
(I am reminded of the Drake Equation for determining the likelihood of other
life like us in the Universe... :-):
http://www.activemind.com/Mysterious/Topics/SETI/drake_equation.html )
Maybe some here of a more mathematical bent than me could produce a similar
formula, outlining the risk in maintaining COBOL and incorporating the
factors mentioned above...plus any others you may think of... :-)
Even without the lines of code, there are all the other factors like
continual business requirement for change, poor programming style, lack of
knowledge of the application, pressure of deadlines, corporate culture,
motivation, and so on which can play a part in more maintenance being
required.
On the other hand, if your application is built from small classes, each
comprised of, at most, a few hundred lines of code (I'm talking COBOL here;
typically, C# code is MUCH smaller (because it is tighter and more powerful)
than what COBOL requires to do the same job...) , with each component having
a clearly defined interface and behaviour(s), then you are starting to
minimise the risk of messing with it. In a worst case scenario, you could
drop or rewrite an offending object; it is much more serious when the units
are many times larger.
Given that objects in a class can inherit from each other, extending
functionality is pretty simple. You can add a new behaviour to the class,
secure in the knowledge that what went before will not be affected (none,
part, or all of the previous behaviours can be inherited or changed
(overridden) by the new one, without any impact on anything using the
existing behaviours.) Any process using an object sees only what the object
wants it to see. You can decide how much of it is "visible" when you write
the class.
Bottom Line: By keeping granularity small, the risks for maintenance are
minimised.
Summing up:
Over the years we've had fierce debates here about the merits of OO as
opposed to Procedural programming. While a few of us were persuaded that OO
was important, there wasn't a background of experience with classes and
objects across different environments to be able to grasp the essence of it
and explain it succinctly. People here are now are starting to realise that
the future belongs to objects. Why this is so, I have tried to lay out
above.
There is nothing wrong with COBOL (Procedural or OO). The problem is in the
changing needs of the world, and the costs of meeting those needs. When
there was no other option, what we did made sense. Now, there are other
options and COBOL doesn't really compete.
Michael posted and showed that at least MF OO COBOL is a pretty impressive
implementation. But it is an interim solution that can extend existing
application life, not carry those applications far into the future.
(Actually, it technically CAN carry them far inot the future for as long as
there is support available, but, in practice, it won't, because, as
programmers become more familiar and comfortable with OO programming. they
realise it is better implemented in other languages. It's not like you CAN'T
do something, it is more like it is tedious to do it compared to a different
language. As programmer productivity has a major bearing on the budget
bottom line for most IT departments, it isn't too long before COBOL dies of
attrition.
(Of course there are other factors which are leading to the removal of IT
departments for development altogether, but that is beyond the scope of this
discussion.)
The future belongs to classes and objects, and that will be the basis for
system design, as well as for programming.
Pete.
--
"I used to write COBOL...now I can do anything."
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- Re: Layers, objects, and granularity
- From: James J. Gavan
- Re: Layers, objects, and granularity
- Prev by Date: Re: SemiOT: problem with XP Service pack 3 followup.
- Next by Date: Re: COBOL ain't quite dead - yet !
- Previous by thread: Alpha-release of OpenCOBOL Lua interface
- Next by thread: Re: Layers, objects, and granularity
- Index(es):
Relevant Pages
|
