Let me begin by introducing myself. I began working with Progress in 1984 and I have been a Progress Application Partner since 1986.

Transcription

1 Let me begin by introducing myself. I began working with Progress in 1984 and I have been a Progress Application Partner since For many years I was the architect and chief developer for our ERP application. In recent years, I have refocused on the problems of transforming and modernizing legacy ABL applications. Object Orientation is widely accepted as a preferred paradigm for developing complex applications by much of the programming world and now that OO features are now in ABL, I and others have been exploring the benefits of using OO in ABL. 1

2 So, here s our agenda for today. First we are going to talk a bit about the buzz of Good OO, then see how this compares to other kinds of good ABL, then explore why OO best practice is different from traditional ABL, and then look at some examples of Good OO. 2

3 First, a bit about why Good OO is of interest. 3

4 It is my perception that, in forums and other interchanges among ABL programmers, it is fairly common for people to talk about Good OO or Not Good OO with respect to some practice or design, more common percentage-wise than it has been to refer to other kinds of ABL best practice. Why is this? 4

5 Certainly, one reason is simply that there is a lot more to Good OO than traditional ABL best practice. There are blogs, books, forums, etc. talking about various aspects of Good OO. There are many formalized rules published and discussed at length. Once one knows the name by which a particular rule is called, e.g., Separation of Concerns, a little googling can produce an overwhelming amount to read to explore the topic further. In fact, one of the distinguishing aspects of Good OO is that many principles have such commonly agreed formal names. 5

6 Another aspect of being larger is that Good OO is not confined to a single language and so has become both more generalized. Statements of what is or is not Good OO are in terms of general principles, not specific language elements and thus apply in a much wider range of contexts than many ABL principles. 6

7 And, Good OO is not just recommendations about the use of specific language features and constructs, but derives from well articulated theory. Thus, any one principle can be connected to that theory and is reinforced by it and the whole gains a certain coherency that one doesn t get from a collection of isolated rules. 7

8 Before going any further, let me note that while I talk as if Good OO were one set of rules about which everyone agreed, in practice there is a diversity of opinion on a great many, if not most points. In some cases, this diversity is even great enough to include polar opposite views. Nevertheless, there is a lot of coherence in opinion, especially if one chooses one s mentors carefully, so I think it is justified to consider Good OO as a meaningful reference. Let me also note that there is a lot of variation in how well these rules are observed. There are many people aware of these rules who somehow forget to apply the rule to their own work, particularly if they are experienced. There is some tendency to think that rules are for new people who don t know any better, but that those who have a track record don t need to keep checking their work. 8

9 Having talked a little bit about why Good OO might be of interest, let s take a look at what that traditional ABL best practice looks like. 9

10 Some examples of traditional ABL best practice include: Avoiding the use of FIND FIRST in most circumstances because it is meaningless with a unique key and suggests normalization violations with non-unique keys. Declaring most variables as NO-UNDO so that their state will not be tracked in local before-image files. Strong scoping record references to limit the persistence of locks and transactions. Use uniquely named buffers rather than default ones to help clarify the scope of buffers. Note that the first two are quite specific language features while the second two have to do with a somewhat broader concept of program structure. All are pretty ABL-specific, although each can in some way be tied to a more general principle. 10

11 There are a variety of ways in which ABL best practice gets defined and codified. Some best practice recommendations can be found in the PSC documentation sets, although there are many who would say that the documentation is a far richer source of bad examples than good. Both PSC staff and independent consultants periodically make best practice recommendations in presentations to Exchange, PUGs, various conferences, and on-line forums. Often, the most direct set of recommendations will come from a senior developer to a junior developer within the same company. And, there are a few books, but not many people have ever seen them and what books there are go rapidly out of date. Note that, with the rare exception of the few books, most of these are quite informal contexts and one has to be there at the right time to benefit. In general, there is not a good place to just go look up best practice rules and educate oneself. It is remarkable in some ways how often the same principle will get discussed on one of the forums, always with someone who reacts as if it were new. 11

12 As you might guess from the prior slide about how best practice rules get created, the dissemination of these rules is typically closer to accident than it is to education. Yes, a few people do take training classes and occasionally consultants will do systematic training or mentoring, but for most people in most cases exposure to a best practice rule is a result of it being brought up on a forum or included in a talk, or possibly, just an exchange between individuals. Consequently, best practice rules are not very much a part of a common ABL culture. I suppose there might be a few I hope there are at least a few which are widely shared, but my impression is that most people are not systematically exposed to most rules. 12

13 As a consequence of these patterns of dissemination, there are barriers to wide adoption of traditional ABL best practice rules. The biggest barrier, of course, is that if one never hears of the rule, one is unlikely to adopt it. With limited channels of dissemination, there are limited opportunities for learning. This is why every company should actually encourage participation in on-line forums like PSDN and PEG since it will undoubtedly lead people to becoming better programmers. There is very limited shared culture among ABL developers. Many are stuck in small companies with few other developers with whom they can interact. A few come to meetings like these and learn more, but many don t. A few attend larger conferences like Exchange or the upcoming PUG Challenge Americas, but most don t. A few participate in on-line forums, but most don t and many are not even allowed by their employer to do so at work. Often this leads to a house style the way we do things here which h is internalized by all the developers in a particular shop, whether good practice or not. In fact, in many cases the house rules can even be bad practice, like the convention of always using FIND FIRST out of the mistaken impression that it is faster. Often this house style comes from copying the way things are done in a purchased application most of which have their origins years back and weren t models of good practice when they were new. All of which leads to a lot of ABL code that is not as good as it could be. 13

14 So, what makes OO best practice any different from traditional ABL best practice? 14

15 Unlike traditional ABL best practice, Good OO was already well defined, documented, and discussed long before ABL ever got OO constructs in the language. It was defined based on work in many languages, all grounded on principles of Object-Oriented Analysis and Design, which is independent of any language. It is documented in book after book, web page after web page, and discussed in person, on lists, and on web pages at great length. This high availability contrasts with the sporadic nature of advice on traditional ABL best practice. 15

16 Another big contrast is in the formalism and completeness of Good OO principles compared to the ad hoc and unstructured nature of traditional ABL best practice. That all of the rules we are going to discuss today have commonly accepted names is indicative of this formalism. This formalism comes in part from there being multiple competing methods of application development which were then combined into a single modeling symbolism known as UML (Unified Modeling Language) in the mid 90s. While UML is not a development methodology, it has provided a common drawing standard on which these methodologies could continue to evolve. We have never had this kind of rich body of theory applied to ABL, much less many businesses which existed solely to teach others about how to do analysis, design, and development effectively and efficiently. 16

17 You may be asking yourself, OK, so there is all this theory and method out there for Good OO, but it has all been created for 3GL OO languages like Java and C++ does this really apply to ABL? 17

18 The answer is yes! There may be places where one will choose a different implementation in ABL, e.g., one that uses a ProDataSet, but the principles of Good OO are principles of OO Analysis and Design which apply to any language. I.e., the implementation may differ, but the principle is likely to remain the same. 18

19 Moreover, it is likely that you will find many of these principles provide good guidance to non-oo programming as well as OO. Not all of them, since there is definitely a different mindset to OO programming, but many. 19

20 Let s now take a look at some principles of OO best practice. 20

21 The first best practice we are going to consider is encapsulation an idea basic to OO thinking. Essentially, encapsulation means that t a class, i.e., a program unit, should implement a single responsibility and it should hide the implementation of that responsibility in the contract for the class, i.e., expose only what needs to be exposed to fulfill the contract. A contract is simply the specification of the responsibility which the class agrees to fulfill. In saying this, we are introducing a couple of familiar words that have special meanings in OO, so perhaps we should review these first. First, there is the difference between class and object. A class is the name for a set of entities which have common behavior and elements of knowledge. An object is a specific instance of a class and thus has the state of a single entity that is a member of a class. Responsibility is a common word in OO thinking and indicates a somewhat different way of thinking about code than we are used to in traditional ABL. A responsibility is an obligation to know or do something. The contract describes this obligation. In traditional ABL we often think in terms of the implementation, i.e., we know that a particular set of code does a certain thing. In OO, though, we very strongly want to think only of what we are expecting that unit of code to know or do, not at all how it does it. The contract should be the minimal required for it to perform that function. We tend to talk in OO about knowledge and behavior instead of data and code. The choice of both words reflect our focus on the responsibility for members of the class to do something, i.e., know something or exhibit certain behavior, rather than on how it is that they accomplish this. Often, knowledge will correspond to a simple variable in an object, but it may be computed or derived without us knowing any different from outside. One often distinguishes between knowledge something that one counts on all members of a class knowing and state the particular value which a piece of knowledge has at a particular time in a particular object. 21

22 There is a significant difference here from what we are used to in traditional ABL in that we are expecting the class to contain both knowledge and behavior independent of the source of that data or any awareness about how it is stored. In traditional ABL, we tend to be very conscious throughout in how data is stored and, except for clients in multi-level architectures, we typically expect to just reach out and grab any data we need wherever we need it. In OO, the data or knowledge within a class is just there. It is the knowledge needed to perform a responsibility with no awareness of what happens before or after. This makes a lot of sense. For example, an Order needs to provide Order behavior whether the data came from the UI, the database, or from some service. While the order is being processed, the data in the class is just the data about the order regardless of where it came from. In the end, we may want to store that data, but there might be other cases where the result is that we send the data off somewhere else, our responsibility being ended. So, the knowledge and behavior of the Order class in independent of the source and disposition of the data it processes. 22

23 Separation of Concerns is perhaps the other core concept in OO programming. Simply, Separation of Concerns, means dividing an application into components so that components overlap in functionality as little as possible. I.e., each piece of code has one concern or one responsibility and that responsibility is shared with no other code. This may seem like an obvious and simple idea, but it is central to the OO way of thinking. I m sure that some of you will be asking yourself, doesn t everyone do this? But, ask yourself How many different places is the customer table accessed in your application? If you wanted to see all of the logic which is ever applied to the data in the customer table, how many different places would you have to look? Do you even know where all those places are? If like most applications, functionality is spread broadly instead of being clustered in one place. Thus, not only is the functionality for a single entity spread, but the functionality in any given program unit is often a mixture of functionality for multiple entities. E.g., Order code will contain some of the logic for dealing with Customers so the Order code is mixed and the Customer code is spread. This is a principle which can also be applied to traditional ABL code. 23

24 The Single Responsibility Principle can be seen as the complement of Separation of Concerns, i.e., that t each responsibility should be its own class. A responsibility is an axis of change, so if there is a change in one responsibility, it should impact only one class. The obvious exception is if the change implies a change in the public contract of that class. Even then, change in any other class should be limited to having to respond to that changed contract. This is a principle which can apply equally well to non-oo code. Sometimes, particularly with large, complex responsibilities, one will find all the code for a particular function in one place, referenced where it is needed. To do anything else would seem foolish. But, it is quite common for fairly large amounts of only slightly different code to be copied here and there in the application and it is very typical in traditional ABL applications for small bits of essentially identical code to appear numerous places in an application. Take, for example, an application where customer addresses have a 5 digit zip code. A new need arises in one part of the application for a 9 digit zip. With an OO structure, we have one class responsible for storage which has to be modified to accommodate the additional data and one CustomerAddress class which handles providing that data to other components. If we preserve the contract which supplies the 5 digit zip and add a new contract which adds the additional four digits, then absolutely every place in the application that used to use only the 5 digit zip can continue to do so unchanged while the one component which needs the additional information can be modified to access the new contract. Absolutely minimal change with complete confidence and complete independence on how we actually store this information. Compare that to having to review every access to customer address. Yes, we can minimize rework by storing the two parts separately, but then we are allowing usage to dictate storage. With the separation, storage can be whatever we choose because the contract is preserved. 24

25 In OO programming, it is common to define what are called interfaces. An interface is an abstract definition of a particular contract which is then implemented by multiple classes. For example, one might decide that there were certain behaviors common to all wheeled vehicles and define an interface with methods corresponding to those behaviors. This interface could then be implemented by a number of different wheeled vehicle classes. In programming, whenever one needs only methods in the shared contract, one can reference any of the classes which implement this interface by referring to the interface instead of the specific class. By programming to the interface, one programs to the contract, not the implementation. Multiple implementations can all respond to the same contract. Any change or addition in the implementation requires no change in the consumer. Those of you familiar with inheritance will recognize a similar purpose. Inheritance is for when there is actual shared behavior and knowledge while interfaces are for where there is just shared contract, but the implementations are different. Both techniques have their place. For designing, this is equivalent to the notion of Design by Contract, i.e., designing according to the contracts which classes present without regard to their implementation. Traditional ABL does not have interfaces per se, but the idea of designing g and programming to a defined contract is still applicable. Any time one programs with active knowledge and use of the implementation of another component, one is violating this principle of programming to the contract. 25

26 When there are complex responsibilities with many parts, there is a choice between modeling this set of responsibilities with generalization or composition. In generalization, one creates a hierarchy with the shared behavior in a super class and specialized behavior in subclasses. In composition, one moves areas of responsibility into separate classes which function as delegates or associates to the main class. When possible, we should prefer the latter since the separation of responsibilities is greater and the classes simpler and more cohesive. One of the common applications of this principle are in cases of so-called crosstab inheritance. For example, suppose that we have a system in which orders can be either for external customers or internal ones and there is some difference in knowledge and behavior between these two types, e.g., billing and credit are handled differently. And let us also suppose that there are different order types according to the fulfillment method direct ship, drop ship, manufacture to order, etc. If we try to build both classifications into a generalization hierarchy, we have an immediate problem since one subdivision has to come first. I.e., either we have the Order superclass with subclasses Internal and External or we have the Order superclass with Direct, DropShip, etc. subclasses. Whichever we pick, we then need to duplicate the breakdown at the second level. I.e., Internal has to have InternalDirectShip, InternalDropShip, etc. and we also need ExternalDirectShip, ExternalDropShip, etc. This is going to mean duplication of logic and a very fragile structure which is easily disrupted by change. Instead, suppose we make a OrderCustomer super class with Internal and External subclasses and move the customer information out of the Order itself and do the same with the fulfillment method, we then have a simple, stable structure in which the OrderCustomer responsibility has been isolated in one hierarchy, the OrderFulfillmentMethod responsibility has been isolated in another hierarchy and both cooperate with Order to form the needed functionality with no duplication and no fragility. This principle is difficult to compare to traditional ABL practice, but the idea of preferring to break complex code into small coherent pieces versus using large blocks of code that do everything is certainly valid in that realm as well. 26

27 Fundamental to OO thinking is the idea that the computational space is a model of the problem space, i.e., there is a one to one correspondence between a thing in the problem space and an object in the computational space. When there are multiple things that have the same behavior, but different state, then we say that they belong to a class. We may organize classes into generalization hierarchies and cooperating sets, but in every case we can make a one to one map from something in the problem space to something in the computational space. One of the implications of this approach is that a domain expert should be able to recognize the entities and their interaction even if he or she knows nothing about programming. It is felt that this natural correspondence of problem space and computational space results in fewer errors, better quality, and the more natural correspondence of code to problem space leads to easier maintenance and evolution. There is no reason not to program traditional ABL in a similar fashion although it is a bit harder to express without OO language constructs but, it is far more typical to think of the computational space as separate from the problem space and to structure it according to its own rules. 27

28 A consequence of connecting classes by the minimal contract necessary to provide for their interaction is that the farther apart two classes are, the less likely it is that they will even know about a class s complete contract, much less any particulars about its implementation. Thus, classes which are in different packages, subsystems, or layers will know very little about each other, even possibly not knowing which class in a package will even respond to a particular message. Thus, packages, subsystems, and layers are typically loosely coupled. By comparison, since classes within a package are parts of a single cooperating set, they are likely to be aware of larger parts of the contract of other classes within the same package and are thus more tightly coupled. There are a number of specific principles which echo this general idea in the whitepaper on my web site. Thus, one might have a printing subsystem composed of multiple cooperating classes which know about each other s contracts because they are mutually independent, but another package using the printing subsystem will be unaware of this structure and merely send print request messages to the printing subsystem. This is a principle which is equally relevant to traditional ABL. 28

29 Normally, one thinks of Separation of Concerns is a very local way, i.e., one class relative to another class, but the same principle applies at the package and application level. In particular, one should start in considering an application or suite of applications by dividing responsibilities among subsystems such that each subsystem is cohesive, i.e., represents a single high level area of responsibility, and responsibilities do not bleed across subsystems, i.e., they are cleanly separated. While perhaps more natural to OO, this is a principle which can be applied to design in any language. 29

30 One of the consequences of clear Application Partitioning is that we can choose to look at a group of interconnected subsystems, each at their own level of detail according to the task at hand. Thus, if we are focusing on one subsystem and thus want to examine the details of its operation, we should be able to look at any connected subsystems at a very high level with no details and still have a consistent view of how the subsystems interact. If we cannot do this, that is an indication that details of one subsystem depend on details of another and we have thus failed to achieve the desired Application Partitioning. The printing subsystem mentioned earlier provides a good example. When we are looking at the printing subsystem itself, we can consider the detail, but treat all other subsystems as black boxes which merely send print request messages. Conversely, if we are considering a subsystem which uses the printing subsystem, we should be able to consider the printing subsystem as a black box which merely handles the print request, without any knowledge of how it does so. Again, while this is natural to OO and particularly apparent in UML diagrams of OO systems, the principle is one that can apply equally to traditional ABL. 30

31 Perhaps one of the more important shifts of orientation between traditional ABL thinking and OO thinking is the move from Do This to I m Done Doing This. Do This creates a dependency of the sender on the receiver which frequently cascades to create hierarchical structures of dependency which are fragile, difficult to understand, and hard to modify. By having the sender announce I m Done to interested parties, no dependency is created beyond that of simply sending and receiving the message about the event. Everything else happens within the object, i.e., a single area of responsibility for which that object is the implementation. The resulting systems are far more stable and more easily modified because the scope of any change is limited to a single responsibility contained within a single class. They are also easier to understand because each class is a single responsibility which can be looked at in isolation. There is nothing to prevent applying this principle to traditional ABL and it is, in fact, characteristic of publish and subscribe mechanisms, either locally or across the bus. 31

32 A core theme in OO is separating what is common from what is different. That which is common, i.e. unchanging or invariant i across a group, becomes code that t is shared across all members of the group. The differences between group members then are expressed as data or state.. Thus, in the problem space, we have many entities. Some of these entities we will recognize have common behavior, but differ in the details of their state. This group then becomes a class because we have one set of behavior and one set of properties for each entity. Each individual object shares the behavior, but has its own values or state for the properties. Thus, in the problem space or real world we might have a number of entities, say trucks. This group of trucks will some common behavior and some common knowledge attributes and therefore is a good candidate for a class. The common behavior becomes code in the class. The common knowledge attributes become properties of the class. The specific state of those attributes, e.g., VIN number, make, model, color, etc. is the state of any one object of the class. One can also have clusters of shared behavior and knowledge. For example, one might recognize that there are both trucks and cars, each of which make a good class since each has a set of shared behavior and knowledge. But, one might then recognize that some of the knowledge and behavior of a truck is also knowledge and behavior of a car. This prompts us to create a vehicle superclass. The common knowledge and behavior goes into the superclass. The knowledge and behavior common to trucks but not to cars goes in the truck subclass. The knowledge and behavior common to cars but not trucks goes in the car superclass. Thus, anything shared by a group has been encoded and only the state differs among individual objects. The implications for the size of an application, i.e., non-duplicated behavior and knowledge, and for reliability are enormous. There is nothing to keep one from thinking this way in traditional ABL and, in fact, the use of common library procedures for shared behavior and persistent and super procedures for common routines is certainly a step in this direction. 32

33 33

34 We have talked about: Why Good OO is more conspicuous Where traditional best practice comes from How traditional best practice is disseminated How Good OO is different Some examples of good OO principles Which of these principles also apply to non-oo 34

35 Here are some links for more information. Generally, look on OE Hive under OOABL and look at the articles section of our website. 35

36 Thank you. 36

37 And now for questions. 37