RE: OO / Procedural Productivity

["Paul Holm" <pholm@xxxxxxxxxxxxxxxxx>]

Nathan,
Thanks for the feedback.   I truly enjoy these perspectives and debates.
I'll again provide my perspective for what it's worth along with some
concrete examples.
IMHO:
1. OO is not necessarily Java, OO is a set of "smart programming techniques"
designed for productivity.  OO concepts can and have been applied in
traditional environments.  For example, OS400 is Object Based which is a
subset of full OO.  OS400 support objects with defined intetrfaces,
encapsulation is handled in the MI.  It false a little short since you can't
create your own object types.  (except with new DB support)
2. Other OO concepts on the iSeries consist of Field Reference files.
Fields are defined once and referenced in multiple files.  Changes to the
reference object (field) can be propagated to all referrers.
3. I may be missing something in your example, but I would argue that if you
have a design as you mentioned then YOU ARE implementing OO type technology
in your RPG domain.
4. IMHO, it appears that you have a reusable framework for query, and IO
capable of  a certain amount of reuse and flexibility which is a good thing
meaning productivity however it appears you are only "moving the data from
the DB to the UI back and forth similar to Query/400 and DFU.
5. However, most business application I'm involved in require intelligence
propagated and enforced by the UI.   Do we hit limitations with your fw when
we need intelligence?  Let me provide an example:

Human Resource app where we are searching for employees.  When the list is
presented, business rules state that the application is not to allow updates
to "managers" because managers follow a different set of rules, etc.
THEREFORE the UI should not present an edit icon in this case.  Additional
rule may be that  any non manager should not be allowed a salary > 125,000
per our salary grid.  If a salary is set higher than 125000, disallow the
update.   These are hypothetical examples for illustration but I think these
common requirements may limit your utility.  For example, how can you
override a particular table assigning an intelligent Bus object that will
override the default IO behavior.  Common patterns in this area include:
a) Applicable  - Sometime certain fields are not applicable and shouldn't be
shown
b) Required -  Readable, editable, etc
c) Possible values,  when presenting the transaction codes that possible
values are:  deposits, withdrawls.
d) Etc.

To accommodate this in OO, our business objects could override these methods
such as "isEditable".   IE.. If the employee is a manager, this record
cannot be edited.

The following application illustrates this:  (NOTE:  This is a Dev server
that is up and down as we load enhancements, fixes, etc, please be kind to
the data.  :^)  )
There are two operations, one that lists all employees and one that allows
selection by dept.  Both have the same rules.  Don't allow manager updates
and no salary over 125K.
http://www.planetjavainc.com/wow60/run?id=298

Here is the single class that implements this business behavior  in the
sample app in two simple methods that are automatically called by the
framework.
import planetj.database.*;
import planetj.dataengine.exception.*;
import planetj.dataengine.*;
/**
 * Example class to illustrate OO and Framework Designs.
 * Creation date: (3/18/2004 7:59:33 PM)
 * @author: Paul Holm
 */
public class Employee extends planetj.database.Row {
/**
 * Check to see if this Row may be edited.  By default, all Rows may be
 * edited.  Subclasses may override to implement a different behavior.
 *
 * @param ec  context in which application is executing.
 *
 * @return  true if Row may be edited; false otherwise.
 */
public boolean isEditable(ExecutingContext ec) {

        try {

                // If the employee is a Manager or Nathan (just an example) 
don't allow
the Row to be edited
                if (getValueAsString("JOB").equalsIgnoreCase("MANAGER") ||
getValueAsString("FIRSTNME").startsWith("NATHAN")) {
                        return false;
                }
                else {
                        return true;
                }
        }
        catch (Throwable t) {
                t.printStackTrace();
                return false;
        }

/**
* Validate if the operation can be performed on this Row.
*

* @param: int pOpteration Constants stored in Row  ie. Row.INSERT
* @param: java.security.Principal pUser
* @exeption DataEngineException if a this any field is invalid.
*/
public void validateRowOperation(int pOperation, java.security.Principal
pUser) throws DataEngineException {


                switch (pOperation) {
                        case (INSERT) :
                                // Whatever you want to validate on insert
                        case (UPDATE) :

                                { // If the employee is a Manager they can't 
have a salary > 125000
                                        if ( (! 
getValueAsString("JOB").equalsIgnoreCase("MANAGER")) &&
getValueAsDouble("SALARY") > 125000) {

                                                throw new 
DataEngineException("Hey they ain't worth that much! Lower
that salary!");
                                        }

                                }

                        case (DELETE) :
                                // Whatever you want to validate on delete
                        case (COPY) :
                                // Whatever you want to validate on copy
                }
        }


}


}

6. Would you have to copy or code for each case to make your XML conversion
occur?  I smell a pattern....


Just friendly observations.

Thanks,  Paul Holm