Voice: 919 848 9898 Fax: 919 254 3449

Patterns [5] address the need for solutions to common problems in a well-defined context. Ideally, the solution is easy to use and adapt to the learning situation. Therefore, developing a pattern can be seen as a bottom-up process, where a recurring solution is used to address (at least three) common problems, and the solution is then abstracted into a pattern.

AntiPatterns [3], on the other hand, identify common problems with solutions, and then show how to refactor the solution to get rid of the problem. Therefore, developing a AntiPattern is a top down process, where the (at least 3) problems with a recurring solution are identified, and then a best practice refactoring of the solution is developed to address the problems. The problem, solution, and refactored solution then get put together into an AntiPattern.

OO learning AntiPatterns identify problems to solutions for teaching/training people in object technology and presents a refactored solution. This article presents an initial set of 8 learning AntiPatterns.

For this article, we will use the mini anti pattern template as described in [3]:

AntiPattern Name: What shall this AntiPattern be called by practitioners?

AntiPattern Problem: What is the recurrent solution that causes negative consequences?

Refactored Solution: How do we avoid, minimize, or refactor the AntiPattern problem?

AntiPattern Name: OO Development, Waterfall Style (Also known as: Iterative/Incremental Development, Waterfall Style)

AntiPattern Problem: Trying to teach an OO methodology from a book usually results in an approach which is workproduct-centric. So, most of the training is based on how to develop use cases, class diagrams, sequence diagrams, and state diagrams in the sequence presented in the book. The design of the training is based on the book, where the agenda is based on coverage of chapters in the book. The main problem is that books are static, and cannot show iterative and incremental development, the cornerstone of OO development. So, the training presents a waterfall style of OO development, where all requirements are defined, then all analysis models are created, and then all design is created. A common complaint for not covering iterative and incremental development is the lack of time!

Refactored Solution: A (industrial strength) methodology is made up of process and workproducts. A book description of the methodology focuses mainly on the workproducts. Base the design of training on the development process. Develop a "typical" project plan from the methodology, which is incremental/iterative, and then base the training agenda on going through several iterations/increments by following the project plan. For example, a use-case driven project plan will develop a few use cases and then take each use case through analysis and design (while iterating through the normal course and the alternate courses), and then tackle a whole increment by driving another use case through analysis and design.

AntiPattern Name: Show Me The "Solution" (Also known as "I want to be like Grady")

AntiPattern Problem: Most object technology training lead everyone to the same "class" solution or the solution known to the instructor. Most exercises end with "here is THE solution", and then all exercises start from the same common solution. The problem with this approach is that it makes students think that there is a single RIGHT solution, rather than the more realistic and important realization that there will always be alternatives in development. Books and articles from OO gurus exacerbate the problem because they rarely discuss alternatives. Rather, they present one solution, which is usually misinterpreted by most to be the only right solution. Another symptom of the problem is the "watch how I am doing it, and reproduce it like me" mentality of trainers. Often trainers can only explain problems/issues based on the "class" solution.

Refactored Solution: An important part of OO training must be on how to evaluate alternative solutions. These evaluation criteria should be effective in determining the pros/cons of the solution. For OO, there are several forms of these evaluation criteria including checklists to evaluate individual workproducts (e.g. [7] presents a checklist for evaluating a class diagram), quantitative metrics (e.g. a class hierarchy should not be deeper than 5), reviews (both formal inspections and informal reviews) based on walk throughs of the models according to defined acceptance tests, and change impact analysis. The best way of getting alternative solutions is to allow the student solutions to be presented and then apply the evaluation criteria to determine the pros and cons of the solutions.

AntiPattern Name: Objectionable Behavior

AntiPattern Problem: Many of the models used to develop OO applications are based on models used in other (data and functional) methodologies. For example, class diagrams are based on the Entity-Relationship model, which is used as the cornerstone for Information Engineering. As another example, the state diagram is based on the StateChart model, which is the cornerstone for building real time, event-based systems. The key problem in transitioning these traditional models into OO methodologies is the way that they are dressed up in OO clothes. Most of these transitions are done poorly, leading developers to misuse these models when using them in the context of developing OO applications. The main problem is that these transitions are not stated wholly in terms of behavior, the main tenet of objects. As an example, consider the inheritance and aggregation associations usually misused in OO class diagrams. Most of the examples given regarding inheritance are based on "real life" situations, e.g. Animal, Vehicle, Plant hierarchies. The problem with such examples is that they say nothing about the behaviors of the different classes and subclasses, and concentrate more on the similarities in attributes (which is the approach taken in E-R modeling). For example, in a Medical Record Keeping System developed for veterinarians, there will be no difference in the behaviors of the various animals, and therefore they do not constitute a reasonable hierarchy. Differences in attributes can be handled effectively by using appropriate data structures, or if very complex, then designated to a helper class that provides services to manipulate the attributes effectively. Another example is that of aggregation, or the is-part-of relationship between two classes. Many of the OO gurus cannot come to an agreement as to the precise usage of aggregation in OO applications. The main problem is that the use of aggregation is interpreted using the data approach: the part belongs to the whole but the whole does not belong to the part, if a part P belongs to whole A, which in turn is part of whole B, then P is also part of B, etc. In fact, UML has two relationships to address this problem: aggregation and composition (a more restricted form of aggregation which binds the lifetime of the part to the whole and does not allow a single part to be shared by multiple wholes.) The main problem again is that the above characterization does not address the impact of the relationship on the behavior of the objects involved. As a last example, consider StateCharts, which are used to define the behavior of entire event-based systems. StateCharts are aimed at describing the states of the system and how the system transitions from one state to the other. Also, in describing the whole system it was necessary to allow activities and actions to be defined on transitions and on entry/exit to/from states. In transitioning StateCharts into OO methods, the problem is how to use this model effectively in the message-based world of objects. The confusion usually stems from trying to describe object interactions (for providing functionality described in use cases) and the state transitions of a single object (throughout its lifetime) using state diagrams.

Refactored Solution: Ensure that every model built to support OO application development can be described in terms of how it supports the definition of object behavior. Most of the concepts used within a model should also be described in terms of its effect on object behavior. For example, to describe inheritance, use the principle of substitutability, which is defined in terms of the following two object behavior rules:

• From the perspective of a client of the superclass, a subclass instance can be substituted for a superclass instance without affecting behavior.
• From the perspective of a client of the subclass, a superclass instance can not be substituted for a subclass instance because it cannot provide the same behavior.

Note the use of the clients' perspective to describe inheritance, thereby forcing inheritance to be based on the services that is provided to clients (i.e. the behavior of the objects.) Note also that the second rule guarantees that there is a significant difference in behavior between the subclass and the superclass to facilitate its inclusion in the hierarchy. For aggregation, the following behavioral rules can be defined:

• The lifetime of part is bound to the whole, implying that the whole has the responsibility for creating and deleting parts.
• The whole has exclusive ownership of the part, implying that only one whole can manipulate a given part.
• Clients must communicate with the part through the whole, implying that the whole must provide (access to) part services.

The reason for making these behavioral rules explicit is that it allows their unambiguous application and allows the realization of the advantages of using objects. As an example, the use of the aggregation rules ensures that the part is completely encapsulated within the whole, and any changes to the implementation of the parts will be localized and not affect clients.

AntiPattern Name: Transparent Objects (Also known as "I can see right through you")

AntiPattern Problem: The key to mastering objects is to be able to look at the system from the perspective of a single object. An object knows about the values of its own attributes (including those defined in its superclass chain), the public and private services that it provides (including those defined in its superclass chain), and knows about the existence of other objects that it references. Besides class specifications (class templates in a particular OO language, usually generated automatically from OO CASE tools), most of the other OO models provide a global system view of the objects in the system. The problem is that most training teaches how to build OO applications from this global view thereby facilitating building OO systems where objects can see more (e.g. attributes of other objects) than they should. A typical symptom of this global view can be readily seen in object interaction diagrams, where one object gets values from several objects in order to do some work. The global view allows a developer to see all the variables in objects and to think in terms of data ("what pieces of data do I need in order to do my work"), rather than behavior ("what services do I need to do my work.") This data perspective violates one of the cardinal rules for achieving reuse: program to an interface, not to an implementation. Therefore the data within one object is bound to the clients that need that data to do their work. Any changes to the data (e.g. changing the year part of a date from two characters to four) requires changes to all clients that use that data as well! This problem is further exacerbated by OO languages (e.g. Java) which allow public access to attributes defined in a class.

Refactored Solution: Force students to take an object perspective when exploring the dynamics of the OO application. Use responsibility driven design [8] to explore the responsibilities and collaborations of objects to satisfy functionality defined in use cases. In particular, the CRC technique [1, 2] is excellent in facilitating an object perspective in dynamic modeling. However, note that the CRC technique does not guarantee an object perspective, especially for novices. To ensure a pure object perspective ensure the following:

• Give students role playing objects a few minutes to "become their objects" by looking at the available models to determine what their objects know about (they can write their object knowledge on the back of the card.) Check the back of these cards to ensure that students have not copied data from objects that they refer to.
• When the students are ready to role play their objects either cover all the models or move them to another room. This ensures that each student can only see what their objects know about.
• During the role play, ensure that students are not asking for something that their object can't know about, especially data. Get students to think in terms of what services do they need to perform their work rather than the data they need.
• After role play, ask all students to look at the public interface of the object and determine if they can tell from the interface what data is stored by the object or how the service provided by the object is implemented. If the answer to either is yes, then this indicates a poor set of services since they expose either the data in the object or the implementation of the service. Such exposure binds clients to the object and leads to problems when changes are made to the object.

AntiPattern Name: Mind Meld (Also known as Cowboys and Cowgirls)

AntiPattern Problem: Developing an OO application is a team effort, requiring the collaboration of team members. Therefore, to be effective, OO training needs to be team based. Unfortunately, most OO training teaches concepts/techniques/methods to individuals. What is lost in this approach to training is how to think collaboratively and work together in designing and developing an OO application. Note that collaborative thinking and work is necessary in building good industrial strength OO applications. Such applications are usually complex enough to require more than one person to build a good object design and implement the application. As an example, it is impossible to use the CRC technique with one person. It is potentially feasible to use the CRC technique with two persons; however, they must be experts working in a familiar domain (for example, Ward Cunningham and Kent Beck designing a GUI builder application.) Most training side step this team based training issue by using a simple case study and by NOT using team based techniques. The common reasons that are given for not using a team based learning approach include the difficulty in handling team work, the inability of all students to learn the same material in the same way, the difficulty in assessing (or grading) the students' performance or mastery of materials, and the "fact" that students learn better as individuals. All of these learning based reasons are myths! This problem is further exacerbated by computer based training and distance learning where the current technology makes team based learning difficult if not impossible.

Refactored Solution: Preparing developers for industrial strength OO software engineering requires team based training -- from the first introduction to objects to the complex implementation of distributed OO applications. The only time that individual training is appropriate is when teaching a product, e.g. how to use Rational ROSE or Microsoft Project. [NOTE: I would still recommend that these tools be introduced in the context of learning OO application development skills.] There are effective solutions to handle the perceived problems with team based learning:

• Team exercises should be well defined and structured to maximize participation and learning. For example, the Plan-Do-Reflect (PDR) structure for team exercises introduced in [6] has been used effectively to define the roles that team members play (ensuring participation from all members) and on allowing the experience to be shared with other teams. To maximize learning, assign a mentor to facilitate the team work. [NOTE: cost is the major issue in training using a mentor with each team. In academia, mentors can be senior students who have successfully completed required courses, and are given credit for managing teams.]
• Teamwork actually enhances the student's understanding of materials. This is partly due to having to explain your approach/solution to your peers, and partly due to seeing how your peers came up with a solution. Furthermore, teamwork allows several alternative solutions to be discussed, which increases understanding.
• There are several approaches to handling assessments/grading. If testing of individuals have already been developed or are available, then these can be used as is to test mastery of materials. More elaborate forms of assessment [4] separate team based grades from individual grades and include several levels of assessment.
• Students learn best when they learn in an environment that matches the environment in which they will put their skills to use. Therefore, students learn OO application development best when they learn their skills in a team-based real application development environment.
• Team based learning can be handled in distance learning situations via conference calls, shared electronic whiteboards, online chat rooms, groupware tools such as Lotus Notes, and shared repositories.

AntiPattern Name: Trivial Compute (Also known as "Oh no! It’s the ATM problem")

AntiPattern Problem: A good indicator of the effectiveness of training is the case study that is used. Unfortunately, most object technology training use simple case studies or no case study at all (i.e. the exercises are not based on the same case study.) The main problem with this use of a simple case study is that it does not reflect the kind of problems that the students will face when they build OO applications. Therefore, students have difficulty in applying what they learned on the job. This problem is most evident in OO programmer training (e.g. programming in Java) where the emphasis is on teaching language features rather than on using the language as a "tool" for solving a problem. Another manifestation of this problem is the use of simple (usually stand alone, single user) applications as the case study. Typical examples of such simple case studies include simple games (e.g. solitaire), machines (e.g. vending machines, gas pumps, ATMs), simplified text editors, algorithms (e.g. performing a search, counting nodes in a graph, etc.), simple banking applications (e.g. account transactions in a single-branch bank), etc. The main problems with using such simplified case studies include:

• The difficulty in applying what was learned on the job, since most of the students' projects will be more complicated.
• The difficulty in exploring reasonable alternative solutions to allow students to understand how to evaluate a solution.
• The difficulty in understanding how to partition the application to determine the impact of architecture.
• The difficulty in analyzing the impact of changes on the application and redesigning the application to make it more robust to changes.

Refactored Solution: To make training effective, the case study should reflect (as closely as possible) a typical situation that the students will find themselves in when they apply what they learned. Ideally, the case study should be customized to a typical application from the domain that the students work in. If such a customized case study is not feasible, then the chosen case study should provide most of the ingredients of a typical application. For example, if the only feasible choice for a case study is a game, then make the game multi-user with distributed clients and allow for saving of the game. Such a game case study exposes the students to a logical three-tier architecture. Note that such an approach does not imply that the students must develop all parts of the application. For example, to explore developing objects in the business layer, build a case study where the clients and the persistence mechanism have already been developed. Students can then concentrate on developing the business objects and connecting them to work with the appropriate clients and persistence mechanism. The important aspect of using the case study during training is that it provides the basis for students to learn the methods, tools, language features, and techniques.

AntiPattern Name: Nothing ever changes (Also know as "We don't have the maintenance contract")

AntiPattern Problem: One of the main advantages of using object technology is the impact on handling changes. Unfortunately, most object technology training handle changes in the more advanced courses (if at all), usually when discussing design patterns. Besides being handled as a special topic, design patterns are usually taught as a "mechanism" for building good reusable designs. Most of the training on design patterns follow the "Gang of Four" book [5], which presents a catalog of 23 design patterns. Knowing the catalog of design patterns helps in its use in developing good reusable designs. However, this knowledge is no substitute for understanding the impact of changes on a system, and in knowing how to redesign the system to be more resilient to changes. The most common reason for teaching design patterns as an advanced concept is based on the fact that some degree of experience and sophistication is needed in order to understand how to apply these patterns effectively. If design patterns is covered in beginning courses, it is presented as an introductory subject.

Refactored Solution: Change impact analysis is at the core of understanding how to use object technology effectively. Therefore, change impact analysis should be an integral part of any training in object technology. As soon as any design is presented, change impact analysis should be used to evaluate its effectiveness. Note that change impact analysis does not require the use of design patterns. Design patterns can be used to show how a design that does not handle changes effectively can be redesigned. The most effective way to perform change impact analysis is to develop change cases for a given use case. Change cases describe the potential changes to the system in the future as it effects the given use case. There are three kinds of changes that can be explored: changes to data, implementation and interface. Data changes explore potential changes to the format and structure of the key data involved in a use case. The classic example of a data change is the move from two character year in a date to a four character year. Implementation changes explore potential changes to the way something in the system is implemented. These changes can range from the implementation of information (e.g. changing a simple key-based order to a first-in-first-out order) to the implementation of a subsystem (e.g. moving from a client-server architecture to a three tiered distributed architecture.) Interface changes explore potential changes to the interfaces of external subsystems. A common example of an interface change is moving from "dumb" terminal clients to web based user interface. The key to change impact analysis is to determine the changes that would be needed to the design in order to handle the different change cases. If each of the changes requires a local modification within an object, then the design is robust. Any changes that require modifications to a primary object and its clients necessitate a redesign. Most of the problems are caused when the design programs to an implementation rather than an interface (for example, clients need to know about the local data held by an object or how its services are implemented.) Once a redesign is deemed necessary, then appropriate design patterns can be introduced to redesign the system.

AntiPattern Name: RAD-DARless development (Also known as Not Invented Here)

AntiPattern Problem: OO software development requires a good understanding of Reusing Abstractions for Development as well as Developing Abstractions for Reuse (RAD-DAR.) Unfortunately, most training build applications from scratch and do not spend enough time on how to find, understand and use what is already available, and how to make objects that are developed available for reuse. Most of the courses on OO languages (and development environments) do cover available class libraries and show how to use and extend these libraries to build applications. However, it is very rare that courses teach how to reuse domain specific classes, libraries, and frameworks. It is even more rare for courses to cover what makes a class, library or framework reusable.

Refactored Solution: During case study work, students should be immersed in a semi-completed application. This ensures that students will have to (re)use what has already been developed. Furthermore, it exposes the students to the difficulties in reusing components and the characteristics of reusable components. After students/teams have developed components, give these components to other students/teams to use in extending the case study. Get the students/teams reusing the components to evaluate and provide feedback on the reusability of the components.

This article has presented a first cut at eight AntiPatterns for learning object technology. To be effective, these AntiPatterns must be validated by practitioners in the field. If you recognize any of these AntiPatterns, have anecdotes associated with these AntiPatterns, have alternative refactored solutions that have worked, or have any new AntiPatterns associated with learning object technology, please send me email.

1. Beck, K., and Cunningham, W., "A Laboratory for teaching Object Oriented Thinking", OOPSLA'89, SIGPLAN Notices, ACM, Vol. 24, No. 10, pp. 1-6, 1989
2. Bellin, D., and Simone, S., The CRC Card Book, Addison Wesley, 1997.
3. Brown, J.W., Malveau, R.C., McCormick, H.W., and Mowbray, T.J., Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis, John Wiley and Sons, 1998.
4. Dodani, M., "Practical Object-Oriented Software Engineering", Invited Paper, Computer Science Education Journal, Ablex Publishing Company, Vol. 4, No. 1, pp. 87-98, 1993.
5. Gamma, E., Helm, R., Johnson, R., and Vlissides, J., Design Patterns, Addison-Wesley, 1994.
6. Lilly, S., "Patterns for Pedagogy", Object Magazine, SIGS Publications, Vol. 5, No. 8, pp.93-96, January 1996.
7. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorenzen, W., Object-Oriented Modeling and Design, Prentice Hall, 1991.
8. Wirfs-Brock, R., Wilkerson, B., and Wiener, L., Designing Object Oriented Software, Prentice Hall, 1990.