MVC is the civilized way to take your /Free and ILE knowledge and build apps that are worthy of your name.

Editor's Note: This article is excerpted from chapter 23 of 21st Century RPG: /Free, ILE, and MVC, by David Shirey.

Let’s take a quick look at what MVC really is.

A Few Basic Facts

First, let’s step back a bit. Start by answering this: how do you go about coding a program?

In the olden days, which for many of us is right now, people built programs by just coding. They would take a deep breath and start at the beginning, go on to the end, and then, hopefully, stop. The result would be a big ol’ program (BOP). When it was done, then they could see what the structure of the program was.

But going in, you have only the foggiest picture of what that structure is going to look like.

Of course, by this point in the book, we know that what we should be doing is writing small modules that fit together efficiently to produce a completed app. But by themselves, writing small modules may not be enough. Because you still end up with a bunch of code entities, and you are still stuck with the question of how to put them together. And if you do that poorly, you end up with a spaghetti of small modules to navigate. How do you avoid that?

The sad but true fact is that even if you are doing /Free and all that jazz, you may still have no idea what the final structure of your program, and by extension your application, is going to look like when you start.

To get a clearer picture, up front and ongoing, of what your app structure is going to look like, you need to be using design patterns.

Design Patterns

Design patterns are a development strategy: reusable templates of software applications.

And the key word there is “applications.” Design patterns are not program models, although they do provide some help in that arena. They are application models, templates for how you should structure and build your application, what modules the app should have, and how those modules should be interconnected—that sort of thing.

In most cases, the pattern is not specific enough that you can just change a few things and all of a sudden you have an application (although in Web frameworks, it can be close sometimes), but it provides the overall structure for the app. In essence, the pattern defines the architecture or structure of an application. Instead of you figuring out where the control statements or business logic will go and how the system will determine what is next, the design pattern does it for you.

It’s not a revolutionary idea. In one sense, all of us have been using design patterns all our coding lives when we use one program as a model for another one. But design patterns take it one step further and provide not just the structure for a program but for an application. Plus, while it is possible that copying one program to create a second is just a way of duplicating a mess, design patterns are well thought-out and organized.

Design patterns are something fairly new in our (the IBM i) arena, but they have been in use on the Web side for quite some time. In fact, that is what most Web language frameworks are based on (a particular design pattern, or several design patterns). When you use a Web framework, you select the design pattern you are going to use, and that automatically generates much of the standard code that you need to make the app work. And it is time for the i world to get on board.

Characteristics of a Design Pattern

Let’s take a little closer look at what a design pattern is and its characteristics.

Module Oriented

First and foremost, a design pattern is built by taking modules and binding them together into an app, not by building one monolithic program.

Fortunately, this is right up ILE’s alley. And, ILE is therefore uniquely suited to design patterns (and therefore, MVC).

OO or Not OO

Second, because the design pattern is oriented around small code modules, it is ideal for OO, but—it is not just for OO, and you can apply it to RPG just as well as to PHP or one of the other cool languages. What I really mean here is not that design patterns only work with an OO language, but that they help you to focus your thinking in the same way OO does.

As I have said before, RPG and other procedural languages point you toward thinking about the process. This is not a bad idea, but sometimes it does tend toward BOPs as the method of delivery. OO thinking pushes you toward thinking about the elements first and the delivery second. I’m not sure if that is the best way to put that, but it helps you think about developing modules first and then linking them together second. And design patterns do start with modules; they can’t really have a BOP design pattern.

Eliminates Decisions

Third, using a design pattern eliminates many of the decisions you would normally have to make.

Things like how your application will be structured, what code elements will go in what modules, how control will flow, and so on. By letting the design pattern specify this, it makes it much more likely that someone else’s inventory application will look a great deal like your accounts payable application.

In the end, it will be easier to understand something you have never seen before because not only are all the modules truly modular, but the structures will be essentially identical as well.

In short, design patterns are reusable structures that are not implemented directly but are used as a “pattern.” They may be designed to solve a particular type of programming question or to represent a particular “problem.” They are not frameworks, but a framework may provide an implementation skeleton for one or more design patterns.

Design patterns are a means of thinking about a particular business or communications problem in a way that helps you organize your thoughts on how you will actually solve that problem.

There Is More Than One (Design Pattern)

More than one? To be honest, there are dozens or maybe hundreds of design patterns that have been identified.

Each pattern is oriented around a particular type of app or problem, and the idea is to pick the one that most nearly approximates what you want to accomplish. Only some of the design patterns will really apply to the solution of a business problem. Many of them relate to messaging or problems that are specific to object-oriented languages and other more technical issues.

Design patterns were really put on the map by the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) when they published their now famous tome Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994). They outline 23 different patterns organized into three basic groups.

Today the number of design patterns has expanded greatly, and there are roughly four different groups into which these fall.

Creational Patterns

These are patterns that, yes, you guessed it, create something.

Examples would be the Builder, Factory Method, Lazy Initialization, and other similar patterns. They result in some type of object or thing being created.

The Lazy Initialization pattern, for example, is a way of delaying the actual creation or value assignment of an object until it is really needed rather than up front when the app starts. Obviously, this is related to OO, as are many of the design patterns.

Structural Patterns

As you might expect, structural patterns define a structure that the app should follow. Another way to put that is that they define relationships between separate components.

Examples of this would be the Adapter, Flyweight, and Decorator patterns.

Most of these are also OO related, like the Decorator pattern that allows you to add functionality to a class at run time. You could always use subclasses to do this, but that can lead to an explosion in the number of subclasses defined. The Decorator pattern provides an alternative to that.

Behavioral Patterns

These patterns are communication oriented, linking modules together and increasing the efficiency of the interaction.

Examples include the Chain of Responsibility, Interpreter, and the Protocol Stack pattern.

The Protocol Stack defines a multi-layer communication hierarchy that handles the transfer of data between different objects or modules.

Concurrency Patterns

These are for tasks that use multi-threading.

Examples are Active Objects, Leaders/Followers, and my personal favorite, the Disruptor.

The Disruptor ensures that every piece of data is owned by one and only one thread, thereby reducing write contention in the app.

Architectural Patterns

Yes, I realize this is the fifth of four basic groups. It came along sort of after the fact, as business users became more involved in design patterns. This is the one that we are really interested in because this is where MVC and its variants belongs. And this is also where the patterns tend to be oriented more toward business than software only. Although Architectural Patterns is not considered one of the traditional “big four” patterns, many people consider it a valid category.

Other examples of this pattern are Data Discovery, Message Exchange Patterns, and Change Data Capture.

Change Data Capture is really a set of design patterns (that is true of many of the previous examples) that identifies and tracks data elements that have been changed to ensure that the proper action can be taken with respect to those elements.

Anti-Patterns

Design patterns are so popular that they have even inspired anti-patterns: application patterns that should not be followed because they are dangerous and anti-productive.

Oooo. That’s right: they are the bad boys of the pattern world. Rebellious. Anti- social. Yet strangely alluring. Drawing the unwary into a life of screwing up things for the rest of us. Beware, these are the patterns your mother warned you about. Unfortunately, many of them are probably pretty familiar to a lot of IBM i developers.

Anyway, I owe the following list of anti-patterns to Paul Watt, whose blog post (www.codeproject.com/Articles/791302/Software-Design-Patterns) highlighted the idea of anti-patterns. I have redone them somewhat, but the essence of the original list remains.

The Big Box Pattern

This one does it all. Everything you could possibly want is in this one pattern. Can you spell BOP? How convenient. No searching around for just the right one, you’ve already got it in place. You just have to figure out how to make it work for what you want to do.

Hopefully, you will not need to make a change in it. Good luck doing so without breaking it for all the other things it does.

Patterns should have a purpose, and only one purpose. If there is more than one purpose to a pattern, stop, drop, and roll. It’s your only hope.

The Optimization Gambit

Another way to mess things up with design patterns is by putting the focus on optimizing a single part of the pattern.

This is something that is easy to do. There are always certain things that a person will naturally think are more important than others and that need to be given a front row seat when it comes to optimizing. The ability to think broadly and give up some efficiency here in order to gain a greater efficiency overall is very hard to achieve. Although I do feel it is a particular strength of mine, along with the ability to always look at the negative side of things. So, if you ever want the worst-outcome option, let me know. But it will be very efficiently presented.

But we know from the work of giants like Leonid Kantorovich (who was instrumental in sealing the Kryptonian city of Kandor in that bell jar) and T.

C. Koopmans (who played bass for Willie Nelson for almost 15 years before succumbing to a tragic chewing gum overdose), linear programming mathematics tells us that a local optimum always leads to a less than optimal global solution. It is only by balancing various local sub-optimal solutions that you can truly get your most efficient overall solution.

In other words, leave the patterns alone; don’t try to improve on them by optimizing.

The Spray Paint Solution

This is related to the Big Box pattern, and for a while (15 or 20 minutes), I thought it was the same. But the more I thought, the more I realized that this pattern is more oriented toward hoping that a change to a given design parameter will act equally across all the situations covered by this pattern.

It is a broad brush approach to changing things. Make a change in one place and let it roll out over a lot of situations. Sounds appealing, doesn’t it?

The main problem here is that by trying to cover too many bases, this option becomes increasingly hard to reuse in new situations.

The Complexity Algorithm

The last anti-pattern I will mention is the use of complexity or system tricks to shorten up and “simplify” a pattern.

Usually, a pattern is not written to minimize the amount of code that is written. It is written to provide visibility in terms of what is being done. Since the pattern is being used over and over again in multiple solutions, minimizing the code length is not important. What is important is knowing what is being done.

Have you ever run into an RPG routine or section of code that used some old, obscure, or technically complex algorithm for the purpose of reducing the number of lines of code? Of course you have. And how has that generally worked out for you?

To be effective, design patterns must be straightforward. They should not be convoluted or involve esoteric components.

What’s It All About, Alfie?

So, what’s the bottom line?

First, design patterns provide not just a model for a program but a model for your application.

Second, the model they define is logical, consistent, and properly structured from a modular point of view.

Third, MVC is an example of a design pattern, and the one that is most likely to be used in a business situation.

So, where do we go from here?

Well, we will continue in the next chapter to zero in on MVC, so please try to control your excitement.

What Ya Shoulda Learned

I know.

You were expecting more.

I don’t know what you were expecting, but I know you were expecting more.

The truth is, MVC is just a design pattern, and design patterns are not that hard to understand. The proof of the pudding, though, is in the use. Stay tuned.

Next time: MVC and Its Variants. Want to learn more?  You can pick up Dave Shirey's book, 21st Century RPG: /Free, ILE, and MVC, at the MC Press Bookstore Today!

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale