I was sitting here at my desk after replacing the window motor in my van pondering this thought:
“Man, I think JSF is trying to emulate the RPG cycle with it’s ‘Life Cycle’ (click here), the exact thing that so many RPGers are trying to get away from.”
Or maybe it is better stated to say I hear many wanting IBM to rid RPG of it “legacy” features. I must admit that I have held my hand high with the same chant, though now I must recant. Yeah, I know I am making a stretch to say the JSF and RPG cycles are the same, but none-the-less the Java community is trying to adopt cycles which RPG has had for how many years now?
Makes my head spin to see all the excitement in the browser framework world. Seems like we are always trying to get back to what 5250 screens have had for such a long time – ease of user interface development. No, I am not ignorant to the fact that green screens aren’t very appealing, but the reality of it remains that if RPG had a new GUI face (and maybe a syntax facelift), it could arguably take the application development industry by storm. Just look at all of the efforts by Sun, Microsoft and Adobe to make yet another, “thicker” browser with their JavaFX, Silverlight, and Flex3 respectively.
Makes me wonder how “legacy” RPG and it’s infrastructure really is. I have been with the language for about 10 years now and I left RPG for awhile to have some fun with Java. I loved Java at first because there were some really nice and flashy things that made my heart twitter (twitter would be like the first time you sit next to your future wife, but before you give the first kiss). But even when I factor in how fast you can write Java code, it still comes down to long-term support of the applications built. The Java frameworks out there are very nice, but I can’t count the hours I have spent trying to make something work in Hibernate or MyFaces that just wasn’t meant to be because the writers didn’t have forethought of how others might need to use it.
That’s what keeps bringing me back to RPG, DB2 and i5OS – the trio that just doesn’t die. It has the best framework out there, mostly because you don’t even know you are in one! I can’t help but think what would happen if the cycle was modified to work with a new GUI interface that was native on the i5. Platform independance (i.e. EGL/Java)? Phooey, that is what vendors (of which I am) say to make people think they need their product. I would much rather have “The Trio” to keep my business running efficiently and reliably at a reasonable cost. When will IBM catch on to the potential gold mine they have already built – it just needs “tweaking”. We can dream can’t we? 🙂
Well, it is time to go back to work.
Oh, and on last note, if you haven’t already, please add the following to your list of blogs to visit: iDevelop
I read the information at the link you provided and I see zero similarity between the JSF lifecycle and the RPGII Input Primary cycle. As explained on the page you reference, the JSF lifecycle is like the lifecycle of a job where the code and data space come into memory, perform some work and are cleared from memory at the completion of the task. I’ve liked some of the other things you’ve written but this one should be filed in the same drawer as your “Modular RPG is a Web Service” article. I enjoy finding where similar concepts exist in RPG and Java. Using Java as a metaphor, I’ve been able to do things in RPG that never would have occurred to me otherwise. Applying rigor to these concepts makes them more useful.
>I read the information at the link you provided and I see zero similarity between the JSF lifecycle and the RPGII Input Primary cycle.
Greg, I stated I was making a stretch – what more do you want? 🙂 Both cycles start before your program gets control and the cycle does additional processing after your program relinquishes control. That is a similarity to me.
>Ive liked some of the other things youve written
Sweet!
>but this one should be filed in the same drawer as your Modular RPG is a Web Service article.
Uh oh. That drawer doesn’t sound like it is a desirable one 🙂 Are you referencing my SOA for RPG Programmers webcast that I just did? Or a different article? I am so busy these days I can’t keep track of them, but I would love to debate whatever I have written, or recant if times have changed and a different approach needs to be made.
>Using Java as a metaphor, Ive been able to do things in RPG that never would have occurred to me otherwise. Applying rigor to these concepts makes them more useful.
Good to hear! Adding other languages (i.e. Java/PHP/C#) to my toolbelt has greatly enhanced my RPG also. Now if we could just take the best from all of them and put it in a single language 🙂
Thanks for your direct response,
Aaron Bartell
http://mowyourlawn.com
Aaron, the article I referred to as “Modular RPG is a Web Service” is in this blog entitled “SOA? WOA!”.
RPG programs that use the cycle are rarely interactive. It seems odd to compare a web UI framework to the RPG cycle which is, in my experience, seen in batch jobs.
RPG programs that use the cycle do have the cycle as a common piece of functionality. In that regard, if the cycle were used to process a DSPF record, it would have some resemblance to the servlet and doPost(HttpServletRequest, HttpServletResponse). But I wouldn’t say that servlets resemble this. Given the current sorry state of RPG development (most RPG programmers know more about the cycle than they do about service programs) I don’t see the benefit of imagining scenarios in which Java frameworks are trying to steal from Grandpa’s RPG.
:::Aaron, the article I referred to as Modular RPG is a Web Service is in this blog entitled SOA? WOA!.
So what part of that don’t you agree with? I re-read it, and a part from some bad humor and dumbing down of SOA I don’t see anything wrong with it.
:::RPG programs that use the cycle are rarely interactive. It seems odd to compare a web UI framework to the RPG cycle which is, in my experience, seen in batch jobs.
I don’t know what to tell you Greg other than that’s why I didn’t write this for any trade rags – it is very much opinion/rant based. You are nitpicking and I have declared twice (once in the original text) that I was stretching the scenario. Did you have a bad taco at lunch?
What I was _hoping_ for was some discussion on their vague similarities and possibly get into discussion concerning the RPG cycle becoming something that could be used for UI development – specifically graphical UI.
Cant we dream?
Aaron Bartell
http://mowyourlawn.com
In that case, I think that as it is generally written, the basic structure of the RPG interactive program is wrong. If we value cohesion, then, in an interactive RPG application, there would be a module that knows only about the screen. In this module, there should be only one F spec, the F spec for the display file. Then, there should be one or more modules for the business logic, assuming we value cohesion. There should be no F specs in these modules. And, there should a Controller that calls the procedures in the display module. Based on the function key or Enter key being pressed or the data entered on the screen and returned to the Controller, the Controller then calls procedures in the business logic module and finally calls a procedure in a Persistence module to update data or to get new information. To me, that is what “procedural RPG” would be about, if there were such thing.
Last week I saw a 21000 line RPG program that has 90 F specs; the whole thing written since 2000. We all know not to expect any better, don’t we? Cohesion in RPG? The response I get when I suggest it is “Why bother?”.
Now we are having good conversation!
:::Then, there should be one or more modules for the business logic, assuming we value cohesion. There should be no F specs in these modules.
Here is where I disagree with cohesion (or what I would term a delegation framework). Purists would have zero direct to PF database access in their business logic or “service” layer. I think purists end up drowning in their workload of trying to make everything fit into an initial concept of excellence when in fact their programming and framework excellence should be that of making something work well given the situation.
So that paragraph was incredibly vague and full of theory words – let me tell you what I really mean. I see RPG programmers trying to emulate the DB access that other environments like Java have with DAO’s (Data Access Objects) where you have a getter and setter for _everything_. One of the main reasons, IMO, that Java and similar languages do this is because they don’t have native/direct DB access like RPG does. We don’t have a choice of which DB to use and correspondingly pick a JDBC implementation. We don’t need to abstract out to gross levels that have multiple layers of configuration files and abstract objects (relating to my use of Hibernate.org).
Instead a measured approach to different scenarios should be taken to determine if the need exists to wrap data access. And even then I find that wrapping only needs to occur if one of three conditions exist:
1. To apply business logic
2. To wrap a file that is constantly changing, and by wrapping it you save yourself mass amounts of recompiles because you can simply add another signature to the *SRVPGM.
A company I previously worked for tried the route of encapsulating EVERYTHING in RPG DAO’s without really any business logic and after going through a few tables we realized we lost a lot of RPG’s beauty through the dynamic use of our DB opcodes (i.e. SETLL, READE, CHAIN, etc). We ended up having to emulate the DB opcodes through sub procedures and try to build partial key lists into each *SRVPGM and also try to account for each logical. So all of a sudden a file DAO was a huge labor expense to initially create and then maintain it – not a wise investment IMO because one of the reasons to go that way was to *save* time.
Good conversation,
Aaron Bartell
http://mowyourlawn.com
Having made a study of the DAO pattern and used the Spring implementation extensively, I prefer almost anything else. The active record pattern used in Rails has a lot of similarity to F-spec IO in RPG and that’s the way I’d go. I’m anything but a purist but, I’d like my business logic to work no matter what is source the of the data – MQ, web, DB2/400. We shouldn’t have to duplicate code just because someone can come up with a reason to couple logic to IO.
The cheapist solution that avoids the overhead of DAOs you described would be to put the F-specs in the controller module I mentioned. It’s not the solution of a purist but it seems to approach “good enough” and avoid a heck of a lot of coding. I’ve always approached controllers as having no value for reuse. Like a sacrificial anode (http://en.wikipedia.org/wiki/Sacrificial_anode), a controller serves to keep the forces of deterioration away from the valuable components, the business logic. There’s an article in Nov 2006 System-i mag about dependency inversion that describes the value of controllers in RPG.
:::The active record pattern used in Rails has a lot of similarity to F-spec IO in RPG and thats the way Id go.
Another developer in our shop is doing alot of RoR – I am drooling to get a chance to check it out. Sounds like I have one more thing to look forward to.
:::The cheapist solution that avoids the overhead of DAOs you described would be to put the F-specs in the controller module I mentioned. Its not the solution of a purist but it seems to approach good enough and avoid a heck of a lot of coding.
I must have missed your point then, because this is the approach I agree with. If it makes sense to put it into a DAO/business-logic *SRVPGM so be it, but if it is just a quick chain without any special processing then an F spec in the controller is just fine. Sounds like we are on the same page.
:::Like a sacrificial anode (http://en.wikipedia.org/wiki/Sacrificial_anode), a controller serves to keep the forces of deterioration away from the valuable components, the business logic.
Very cool analogy!
:::Theres an article in Nov 2006 System-i mag about dependency inversion that describes the value of controllers in RPG.
Just read it. Now I can see why you were so interested in this blog entry 🙂 For other’s reference the article can be found here: http://www.systeminetwork.com/artarchive/20697/index.html (requires subscription)
Aaron Bartell
http://mowyourlawn.com
If we’re in agreement, I don’t understand your reference to “a DAO/business-logic *SRVPGM”.
I advocate placing business logic is in a separate module, independent of any F-spec. The business logic reusable for data from MQ, web and the database. The business logic can accept data from unit tests as well.
Just as one controller can be written to accept data from MQ and pass the data to business logic, another controller can be written with hard-coded data and the results from the business verified in the controller. This is how Don Denoncourt’s iUnit works.
I would not want to couple any controller to any other controller by linking to it on the CRTPGM step so data acccess would not be in the same SRVPGM as business logic.
If business logic is written so that it is tightly coupled to its data source(s) then it is not reusable and the company has incurred the future expense of (1.) manual testing tied to the database and (2.) updating the same or similar logic multiple times.
I guess we need to define business logic, because 99% of the business logic I write in RPG is done while interfacing with Physical Files.
For example, I will have a *SRVPGM named CUSTBLSV (Customer Business Logic) and it has sub procs named Cust_isValid and Cust_getPrimaryAddress. Both of those sub procs would wrap many lines of business logic and DB calls into a single API call that can be used from a web interface, SQL External Stored Procedure, XML web service, multiple controllers, batch processing, etc.
I guess you could call my approach “modular programming as it makes sense”. I take it in your approach you would have the same sub procs in CUSTBLSV, but instead of having F specs for those sub procs to easily do I/O you would instead create another *SRVPGM named CUSTDAOSV and make CUSTBLSV do things like CustDAO_getUniqueRec(custNum)?
If I am portraying your approach correctly, what are the perceived benefits? Note that in my approach I’ve already kept the business logic and DB access out of the controller and view (i.e. saving on recompiles because of file changes).
Aaron Bartell
http://mowyourlawn.com
RE: “99% of business logic interfaces with PFs” – That’s why business logic in RPG is not reusable, not unit testable, not cohesive. It is coupled to a particular few DB tables. When RPG business logic is coupled to other things, that code is duplicated then new other things added to it, right? The amount of RPG code some shops have can be beyond their ability to cope with it. It’s time to recognize that each line of code is a liability as well as an asset.
As in the example given in article I mentioned, a business procedure accepts a PaymentAmount and distrubutes those dollars into a Payment Distribution data structure based on amounts like InsuranceAmtDue, FeesDue, InterestDue and then credit the remainder, if any, to Principal. No IO required – just pure business logic. Sweet cohesion. Unit testable.
In that scenerio, the unit test controller with its hard-coded values can be replaced by another controller that does IO and supplies values from the database to the procedure. Voila – reuse! Give me another controller that gets an XML document from a socket or from the IFS and the exact same business logic will run unchanged.
The description of the Single Responsibility principle states that an object should have only one reason to change. The business logic I described will not have to change because a new data source comes into the picture. The business logic will change only when the business logic changes.
In my little world (and all of Java), anything that can’t be unit tested isn’t business logic. And a unit test precludes a database. Adding a database to the test would make it an integration test. I find more value from how test-first development makes me structure my code than in the simple fact that it gives me unit tests.
So, CUSTBLSV is Customer Business Logic? The two procs can be used from anywhere but, I’m guessing, only to access the AS400 database. Does the Cust_isValid procedure you mentioned just test for the existence of a record or is there business logic involved? If the procedure merely verifies that a record exists as part of the “chain chain chain” of RPG IO, then in my mind, that is IO logic.
Let’s think about creating the NEWCUST controller PGM. It will be the controller for the new customer use case. Since we mow lawns, we only want to consider lawns in three zip codes so that will be our one piece of business logic in this example. Since we’re doing test-first development, we write tests that verify that ClientHasAllowedZipCode returns TRUE when the zip is 20500, 20510 or 22202 (White House, Senate and Pentagon – we want some of that govt largesse). Now we write the ClientHasAllowedZipCode procedure. Those three zip codes are stored in the database but our procedure does not access the database. We will pass the three zip codes to the procedure in an array. This is similar to the code shown in Figure 3A in the article I mentioned. That code does some non-trivial business logic without doing any IO.
As I said previously, I’ve seen plenty or 10000 line plus RPG programs and I’m glad I don’t have to work on them. The good Java developers I’ve worked with create classes of a screen or less of code and methods of ten or fewer lines. RPG coders will never be able to do that until they start to separate concerns from one another.
Java doesn’t have all the CHAIN … IF %FOUND() … ELSE … stuff. Until we start defining tables with foreign key relationships and using SQL, RPG has to have that stuff but it doesn’t have to have it everywhere.
:::So, CUSTBLSV is Customer Business Logic? The two procs can be used from anywhere but, Im guessing, only to access the AS400 database. Does the Cust_isValid procedure you mentioned just test for the existence of a record or is there business logic involved? If the procedure merely verifies that a record exists as part of the chain chain chain of RPG IO, then in my mind, that is IO logic.
You didn’t read the whole sentence. I said Cust_isValid contained many lines of business logic and DB operations. Thus justifying it’s placement in CUSTBLSV. If I was looking for a records existence I would simply do a CHAIN from the controller.
:::Now we write the ClientHasAllowedZipCode procedure. Those three zip codes are stored in the database but our procedure does not access the database. We will pass the three zip codes to the procedure in an array. This is similar to the code shown in Figure 3A in the article I mentioned. That code does some non-trivial business logic without doing any IO.
You lost me. How does the RPG sub proc validate the zip code sent into it by the NEWCUST controller if it doesn’t make a call to the DB? You didn’t specify _where_ the DB access resides in your example. We can’t hardly use your article (i.e. Figure 3A) as a reference point because you don’t have any DB access in ANY of the figures.
:::As I said previously, Ive seen plenty or 10000 line plus RPG programs and Im glad I dont have to work on them. The good Java developers Ive worked with create classes of a screen or less of code and methods of ten or fewer lines. RPG coders will never be able to do that until they start to separate concerns from one another.
I won’t argue that modular programming based on _need_ (emphasis on need) is a great thing. If that means breaking pieces down to one screen of code, so be it – but it has to save time in the long run. I have seen the same Java developers you talk about. They get so excited in their mind that they built a program based on the latest Java findings and lose track of helping their business make money and get things done on time (and done right for the long term). I just want to qualify that I agree on many of your points, but I do feel you are close to going overboard with theory. Your job as a programmer is review what others have done before you, take the good, leave the bad, and develop solid modular business applications. I get the feeling this is a test in theory more than anything. Do you have a full example you can post so I can review all aspects?
Aaron Bartell
http://mowyourlawn.com
I read the whole sentence. I may be wrong but I presume it’s similar to what I’ve seen before, it verifies by CHAINing. Record existance is not business logic even if it is mixed with business logic, in my opinion.
Accessing the DB: I thought my examples using different controllers and the previous discussion of Active Record and F spec IO made that pretty clear. DB Access is from the controller, just like RPG programs do it today, the difference being that one module isn’t the controller for ALL use cases but only for one use case.
“Your job as a programmer”: nuh-uh.
“I have seen the same Java developers you talk about”: nuh-uh. You work with guys who were doing Smalltalk 20 yrs ago, published authors, presenters at JavaOne, speakers on the agile circuit?
“modular … on _need_”: Read Robert C Martin’s articles about DI, SRP, OCP at objectmentor.com. Unlike you, I don’t have the b*lls to disagree with him. You da man!
Sample code: see article.
:::I read the whole sentence. I may be wrong but I presume its similar to what Ive seen before, it verifies by CHAINing.
You are reading into the name of the sub procedure too much. Yes it could be that simple, but as I already stated if I am simply checking for the existence of a record I will CHAIN right from the controller.
:::Accessing the DB: I thought my examples using different controllers and the previous discussion of Active Record and F spec IO made that pretty clear. DB Access is from the controller, just like RPG programs do it today, the difference being that one module isnt the controller for ALL use cases but only for one use case.
Maybe I am just having a dense day. It sure would be nice to see an example of your theory (which is NOT in your article). I can understand CHAINing from the controller, seems we both agree on that point. What I don’t understand is how you can have business logic in separate service programs without data access??? Your examples in the article only paint the picture of doing simple arithmetic.
:::Your job as a programmer: nuh-uh.
I feel like we are going to argue of stupid stuff here, but what didn’t ring true with you in that statement? nuh-uh doesn’t give much to go on.
:::I have seen the same Java developers you talk about: nuh-uh. You work with guys who were doing Smalltalk 20 yrs ago, published authors, presenters at JavaOne, speakers on the agile circuit?
You missed my point. I KNOW these guys are VERY smart. I have seen their work (Apache, sourceforge.com, etc). They write software that attempts to meet every possible need they can think of at the time, and end up writing things so generically it takes a degree just to figure out how you got 15 Java classes into what should have been a simple framework process (thinking about JSF here). There is a time and a place for that type and style of coding – but it doesn’t necessitate that it gets introduced into all types of programming (business logic driven apps). That is what I meant by learn from those guys and take the finer points that are going to work for your business and leave the rest of the stuff on the shelf.
Once again, getting back to what I would really like so we can fully understand eachother – can you put together a simply example with ALL aspects of your approach including DB access?
Aaron Bartell
http://mowyourlawn.com
Sorry but it will be a while. I’m in a new job in a new town and I’m providing on-call support for RPG and Java apps. See Robert Martin’s article on Dependency Inversion (http://objectmentor.com/resources/articles/dip.pdf), the last three paragraphs of page 6. Before we go further, do we agree to agree with Mr Martin that high level modules should be independent of low-level modules so that business rules can be reused instead of duplicated?
If we agree on that, then the next page talks about layering. Layering, as he points out, is best implemented in OO. This is where the “sacrificial anode” part of the design I discussed comes in. We can still make the business rule independent of IO but, because RPG lacks OO, the controller has the dependency that it wouldn’t have in Java.
:::Before we go further, do we agree to agree with Mr Martin that high level modules should be independent of low-level modules so that business rules can be reused instead of duplicated?
Depends on how far you want me to agree on that. I read the majority of dip.pdf but don’t agree with his insertion of abstract classes to disguise implementation if we are talking RPG – I have no comments on the C/C++ side of his arguement.
If you look at page 8 section “Separating Interface from Implementation in C++” he further defines _why_ his abstract classes are necessary, and it ends up being because he doesn’t want implementation to be present in .h header files. I would agree with this, but going back to RPG this is more of a practice refinement than needing to introduce additional layers. For example, I would consider a copybook containing RPG prototypes to be similar/equivalent to Robert’s .h files. Relating it to RPG he is saying “don’t include prototypes for your locally defined sub procedures in the ‘public’ copy book, and don’t include D spec variable definitions that are only used local to the service program”.
You see, with ILE I can change the implementation of a service program simply by changing my library list before the program is called -or- by dynamically activating an ILE sub procedure using system APIs (fairly straight forward). As long as the interface (i.e. RPG prototype) is the same for each implementation there is no problem.
To give an example to that lets say we had three price calculation sub procedures all named Item_calcPrice, but they were all in different service programs in different libraries. Let’s also say that those three different libraries exist because we have three different business divisions running on the same machine. All three divisions run the same screen code but they all have different business logic implementations for calculating item prices for reasons I won’t digress into. Based on the profile of the user as they sign on we will load the appropriate library list and inherently select an Item_calcPrice implementation.
Do you see where I am coming from? Again, once things settle down for you, please provide some code in regards to your recommendation.
Good conversation Greg! Fun to dig into semantics of design every once in awhile 🙂
Aaron Bartell
http://mowyourlawn.com
RE: Depends on how far you want me to agree on that. I read the majority of dip.pdf but dont agree with his insertion of abstract classes
I agree:
>>>because RPG lacks OO, the controller has
>>>the dependency that it wouldnt have in Java
And, we agree that DAOs that only duplicate RPGs native functions (READ, READE, CHAIN, etc) is unproductive.
The controller in the SystemiNews article be modified to give the solution to applying a payment. HELOCTEST is the controller for the use case and it isolates the business logic from the source of the data.
1. add an F spec and IO logic for the table containing the Payment
2. add the F spec(s) and IO logic for the table(s) containing the amounts due
3. replace the hard-coded numbers used in the tests with the data from the tables
Note that in reality, some amounts due are probably not stored in tables but are calculated based on the last payment info and the time since the last payment. This simply introduces more business logic that benefits from dependency inversion. This calculation, if it performs its own IO or calls a procedure that performs IO, has a dependency that prevents its reuse in other contexts.
There is an additional consideration in adopting modular RPG. Old style RPG centralized the IO so that all business logic was dependent on the program’s IO. That had the benefit of reducing logical IO. In most cases where I’ve seen procedures used, each procedure was responsible in some way for its own IO. That almost always causes logical IO to skyrocket. I believe that dependency inversion is necessary in modular RPG to avoid increased logical IO.
One more thing –
I think the application would benefit in some instances by moving some of the IO to a procedure. The procedure would not attempt to reproduce RPG’s native IO functionality. Instead, the procedure simply groups the input from the different files and returns the data in one or mre data structures, however is most useful. In my post above, in step 2, I suggest there might be more than one file to retrieve the various amounts due. My experience tells me that retrieving fees due, interest due, etc. is a commonly performed task so it seems natural to write a procedure for that. As I stated earlier, I recently saw a program with 90 F specs, for heavens sakes.
By proceduralizing the input of the amounts due, the solution more closely resembles Mr Martin’s. But it is not important that it look like someone’s model solution. The important things are the encapsulation of the business logic and the removal of dependencies from the routine that performs the business logic.
>>>because RPG lacks OO, the controller has
>>>the dependency that it wouldnt have in Java
I think RPG and Java can near equally hide a dependency, they just have different methods of doing it. Or maybe better stated they can both hide implementation and simply provide a public interface. Putting an abstract OO layer between a controller and DB/business-logic in Java isn’t avoiding dependency, it is instead making it slightly more “configurable” or dynamic. That relationship of a controller to the IO module still needs to be there, in the end, in some form, or else the the program wont work.
I guess what I hear coming out of my own mouth is what I hear this Martin fellow saying, because in the end he _is_ declaring that there is a dependency from the Policy Layer to the Mechanism Layer to the Utility Layer; he just puts an abstract layer in there to make it a more “configurable” and dynamic dependency – which we can also do in RPG _without_ OO or abstract classes and instead use system API’s and library lists.
Would you agree with that Greg?
Aaron Bartell
http://mowyourlawn.com
I’m not sure it is beneficial to push too much abstraction into RPG. If RPG developers want to program in a different paradigm, they could move to Java or C#. I find they like RPG and won’t budge. Your use of library lists to essentially override between service programs is as far (sometimes further) than I would take it.
The benefit of this abstraction goes to the controller and, in RPG, I don’t value the controller enough to go the trouble. If there are three controllers, one to access MQ, another to access DB2/400 and another to control a DSPF and each provides data to the reusable business logic procedure(s) then the solution seems to provide all I’d want. The business logic is easy to test and to reuse.
I recently heard Dave Thomas (http://en.wikipedia.org/wiki/Dave_Thomas_(programmer)) speak. In his talk, he asked, “Why do we do object oriented development?”.
He quickly answered his own question, “To manage our code”.
That goal, of course, can be applied to RPG as well. I think I’m suggesting a method that provides code managment benefits without imposing a significant cost.
Maybe there are people who want to make the same change a dozen or a hundred times when new business logic is required. I’m not one of them. I want to make the change once and test it to prove it’s right.
Aaron,
The example you asked for is Figures 5, 6 and 7 of the October 2007 SystemiMagazine article “Pattern Recognition: Adopting the Pattern”. Figure 5 is the main line controller, Figure 6 is the data-getter and Figure 7 is the business logic that is independent of the source of the data.
In Figure 6, GetData supplies data from the web request back to the controller.
In another controller, another GetData procedure could supply data it retrieves from the database.