OO / Procedural Productivity -- JAVA400-L

Paul,

You've made some good points about design patterns being a key to programmer
productivity, and delineated some of the ones you use.  Good work.
Following is an example of implementing a design pattern in RPG, which may
even illustrate a few advantages over using an OO approach:


      *-----------------------------------------------------------------

     H CopyRight('2004 - Ed Tech Labs') nomain

      *-----------------------------------------------------------------

     D seekby          S             10A   Dim(2) ctdata varying
     D orderby         S             64A   Dim(2) ctdata varying
     D orderbytxt      S             80A   Dim(2) ctdata

      *-----------------------------------------------------------------

      /COPY *LIBL/QMODELSRC,MBSEARCH

      * ----------------------------------------------------------------

     P navCsrInit      B                   Export

      * ----------------------------------------------------------------

     C                   Eval      csr_file = 'xur110p'
     C                   Eval      csr_seek = seekby(1)
     C                   Eval      csr_cols = 'usrid, usrlname, usrfname, '
     C                              + 'usrrole'
     C                   Eval      csr_order = orderby(1)
     C                   Eval      csr_filter = ''

     P navCsrInit      E

      * ----------------------------------------------------------------

     P navSetFields    B                   Export

      * ----------------------------------------------------------------

     C                   Callp     wtnFldSet('c1':csrColStr('USRID'))
     C                   Callp     wtnFldSet('c2':csrColStr('USRLNAME') +
     C                              ', ' + csrColStr('USRFNAME')      )
     C                   Callp     wtnFldSet('c3':csrColStr('USRROLE'))

     P navSetFields    E


** seekby options
USRID
USRLNAME
** orderby options
USRID
USRLNAME,USRFNAME,USRMNAME
** orderby descriptions
Users by ID                   User ID
Users by Name                 User Name

----------------------------------------------------------------

This module implements a basic search and browse screen.  The user interface
is HTML based.

Note the /copy statement:

      /COPY *LIBL/QMODELSRC,MBSEARCH

MBSEARCH is a generic RPG source member.  Some of my colleages call it a
"model".  The model portion of the code might be as robust as the
corresponding UI design pattern calls for, while the variable portion of the
code (shown above) is quite trivial.

In this case, the model code is fairly robust.  It queries a table and shows
a portion of the result set on the screen.  VCR style links enable paging
(first, prior, next, last).  Other UI components enable navigating directly
to a particular page, changing the order of the records shown, building a
filter (SQL Where Clause), positioning within the result set by key.

The number of rows meeting the selection criteria and corresponding page
count are shown.  The number of records per page may be changed to
accommodate different monitor resolutions.  A checkbox enables users to
individually select records in the list, or hyperlinks may be used to
select/deselect all records, or one page of records for further processing.

The example shown above applies to User Profiles.  But applying the model to
any other database table or view is as simple as copying the variable
portion of the code (shown above) to a new source member, changing a few
lines of code, then compiling and creating an ILE Service Program.  A
corresponding HTML template would also be copied to a separate folder and
modified slightly to accommodate fields from a different table.  The model
may apply to ANY database table or view.

One nice thing about implementing models using a procedural approach is
flexibility in extending them.  For example, a basic search and browse model
may precede a database maintenance activity (add, copy, change, delete), or
simply shown in a popup window, enabling users to select a value from a
list, such as selecting a vendor during purchase order entry.  A module
implementing a database maintenance activity might use both the basic search
and browse model along with a basic file maintenance model, essentially
implementing a form of multiple inheritance.

Adding features to procedurally oriented models has no impact on existing
software.  For example, adding a procedure to the  basic search and browse
model to export result sets to an XML formatted stream would have no impact
on existing applications which had implemented that model.  No need to
change or redeploy existing applications.  But new procedures would be
available to the next application needing it.

It would be hard for me to imagine getting any better productivity using an
OO approach.

Respectfully,

Nathan Andelin.


------------------------------

message: 9
date: Tue, 6 Jul 2004 17:54:42 -0700
from: "Paul Holm" <pholm@xxxxxxxxxxxxxxxxx>
subject: RE: MODERATOR ALERT

Joe/Jeff,
Joe in response to request about how to further analyze approaches and
architectures here is an idea from Jeff that I think is good.  Jeff,   I
agree with your idea, lets get a application to use for comparison.  I
suggest even opening it up for the readers of this forum.  They send in real
world business requirements perhaps even supplying "cleansed" data files
that can be used for the exercise, the group choices one or two applications
and we compare results after application creation.  Readers get the benefit
of the comparisons plus the selected business's get a free prototype.

Joe,  I don't want to belabor the point but you asked and I feel strongly
that this issue is critical to the audience since it has huge ramifications.
Choice the wrong approach and pay for it for years!  You have asked for
concrete examples which I have provided to you in past posts.  I have
provided my opinion about your approach and architecture (server-client)
using specific details (See feedback to Aaron Bartell and his mother
children issue) so I feel like I'm following your "rules of engagement". You
have made your claims about productivity and the appropriateness of OO for
business rules.  I respond because I know Java and more importantly OO work
very well for business rules because I have dozens of production
applications running that do that very thing.  Therefore, I feel I may be
able "prove" this assertion and also point out where procedural techniques
struggle to complete with OO.  I don't like to blow my own horn because I
know I have lots to learn but you prefer stated credentials.  I began my
career developing CL and PLMI test programs to test S38 and OS/400 code
before GA as part of the Mankato - IBM Rochester partnership.  I spent 6+
years in the IBM Roch lab developing OS/400 DB code concentrating on
performance, OPNQRYF, SQL, etc.  I spent the last 5 years of my IBM career
in a consulting organization (PartnerWorld) where my job was to assist RPG
and cobol shops as they moved into OO and modern technology.  I specialized
in Smalltalk and OO and taught numerous classes on the subject.  I got a
chance to work with several dozen ISVs assisting them developing OO code.  I
was involved in the creation of one of the larges OO projects which was the
1996 Olympics where we produced a Client server OO project to serve results,
bio, events, etc to the audience in Atlanta.  I moved to Java when it came
along and then to the San Fran project (there are several reasons for it's
struggle besides technical) and then back to Java.  I've written 2 IBM
redbooks on Java , written articles, and presented world wide.  Ever since
then, I have been working with dozens of other companies building OO based
solutions.  I am not a Java bigot (I prefer Smalltalk) but I have witnessed
what OO can do for companies and IT IS COMPELLING.  And YES you can do
business rules and programming in Java and OO and I can prove it.

I know that you have worked with objects and frameworks but for the benefits
of the iSeries community out there that hasn't got a chance to really
understand OO, here some of the concrete possibilities and benefits possible
with OO.

Application development and specifically Web based application develop is
targeted to solve business problems; no surprise here.  Within these
business problems, common patterns emerge and reoccur often.   For example,
the most common pattern is the "Select and Display Pattern".  This pattern
involves selecting data and presenting it to the user.  The problem is very
similar in most business problems however that data is normally different.
For example, insurance companies want to display policies and claims while
manufacturers want to display orders and bill of materials.  This is just a
single example of a reoccurring pattern.  There are numerous additional
patterns reoccurring from application to application.

Object Orientation (OO) and frameworks allow the development of "generic
software" that can effortlessly handle these reoccurring business problems
and patterns.  OO also allows this generic framework software to handle
processing in a custom manner if the business problem is "similar but needs
a little different behavior".  For example, when an Order ship date is set
and updated on an object, we want to also send an ASN email to the customer
and shipping department.

The benefit to the business is that applications can be developed in a small
fraction of the time typically required by procedural programming.  The
precise benefit amount depends on the amount of framework reuse your
particular business problem can leverage.

Following are a subset of the most commonly identified patterns reoccurring
in business applications categorized by architecture level.  (Imagine
development where you didn't need to write any code to solve these
reoccurring business problems!!)

The Data Base Layer

1. Persistence, the ability to read, write, update, or delete records. At
all these points, a programmer is able to override the default behavior and
veto it or add some additional processing if needed. 2. Paging (subfiling)
support.  The ability to read only 10 or 20 records at a time allowing the
user to page through the data in segments. 3. Associated raw data with
business knowledgeable objects such as a social security number, state, zip
code, phone number, federal express tracking id, etc.  Automatically
propagate these business objects and their validation to the user interface.
4. Automatic validation provided by knowledgeable business objects such as a
phone number validating itself or alerting a user if they entered an
improper zip code or date. 5. Automatic validation to the end user for
required fields.  (I.E.  You must fill in your first and last name when
creating the order) 6. Auto incrementing a field.  For example, for each new
order just add one to the last order number. 7. Cache support.  Often for
performance reasons, you may want to read and hold selected records in a
memory based RAM for a certain period or until someone changes that data
which invalidates the cache. 8. Optimistic locking.  Alert the user or
disallow a record update if a specified field changed from read time to
update time.  Also when updating information (fields), only update the
fields that were changed otherwise you may over write other changes.
Concurrency support allows you to specify if fields can be updated if they
have changed since read time.

The Business Model Layer

1. Leverages information from the database and add the ability to associate
real business objects.  For example, a char(9) field becomes a social
security number.  The social security number field works with framework in
both the UI layer and DataBase layer to ensure an invalid value is not
entered. 2. Associations.  The ability to link business objects together.
For example, an Order business object is associated with OrderDetail
objects. 3. Possible values or pick lists.  Often certain business fields
have a set of possible values.  For example, a WaterPump horse power field
may be values ".5 hp,  1 hp, 2hp, 5hp".  The possible values list may be
influenced by the current user or another field's value such as the water
pump manufacturer. 4. Associative Programming:  The ability for generic
objects to instantiated and to use fields with knowledge of specific field,
table, and libraries. For example a Customer business object can find and
use first name and last name fields generically.  That Customer object can
apply to any number of business data tables.  User interface components
(JSPs) can be created without knowledge of the database that they will be
populated with.  For example, standard Invoice JSPs can be created and used.
5. Default values.  For example, the order country field should default to
"USA" or whenever this record is updated, put the current date into the
last_update_field.

The User Interface Layer

1. Select and Diplay.  Allows for the specification of any selection fields,
allows the user to enter their values with the results displayed.  For
example, a sales agent selects and state and policy expiration date to find
potential new business.  Paging support automatically allows the user to
page through any data returned. 2. Custom field labels.  Usually field names
are not user friendly. 3. Sorting.  Allow the user to sort the displayed
data based on any field. 4. Persistence, working with the other layers,
allows authorized users to update, delete, or insert new data if required.
5. Convert any returned data into commonly requested formats such as MS
Excel or Word. 6. Security.  Only allow authorized users to see information
that they are entitled to.  Allows field level security, for example, a
secretary can see a customers balance but can't change it or only allow
managers to see the salary field. 7. UI customization.

Multi Layer Patterns:

1. Self service applications.  When customer 5676 signs on to the
application, they should only see transactions for customer 5676 not someone
else's.  This is one of the most common business application requirement in
today's era.  Vendors want customers to see their data.  Vendors want
suppliers to be able to see purchase orders.  Banks want customers to see
their transactions. 2. Regular scheduled tasks.  This provides the ability
to run specific user code at certain intervals.  For example, each night at
midnight a process runs that generates a report on claim status and emails
it to insurance agents.  This pattern requires the programmer supply a class
that is called at the defined periods. 3. Security (Authentication): Many
applications need to be secured. Reoccurring requirements in this area are:
a. Valid OS user profile b. Intranet users only c. Only these 3 specified
users d. Based on a database of authorized users.  For example, JDEdwards
supplies an address book with suppliers who may be authorized to use the
application. 4. Flyweight pattern.  For performance and memory reasons when
presenting a list, you may only want to return a subset of the list.  When
the user selects a particular item for display or edit, you need to go back
to the database and get several more fields from the selected record.


Again, these are only a subset of the patterns.  We have identified more
than 150 reoccurring patterns that we have found from working with numerous
iSeries and non-iSeries shops and incorporated them into a cohesive
framework using OO techniques.

The benefit is enormous; I don't spend time coding reoccurring functions as
listed above.  I can spend my time customizing behavior if needed only an
exception basis.  More complex applications need more custom code
implemented inheritance.

This is the benefit of OO and patterns and it can enable you create many or
most applications 2 to 1000 times faster than procedural techniques and this
is not code generation.  It is a set of Java classes that provide a
framework (api). Most procedural approaches involve handling the above
business requirements by coding for each case resulting in highly redundant
development and severely restricted productivity.  Each file accessed and
manipulated may involve a similar amount of effort and coding.

Anyway, that's my experience.  Respectfully, Paul Holm