Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation
In a previous post by our guest writer Dr Jason Sender, he investigated improvements in Oracle Policy Automation rules by applying some of the principles of refactoring. Hopefully the short examples he gave revealed some of the increases in readability, maintenance and flexibility that you can build into your rules.Now, in the second article in this series, Dr Sender looks at Object-Oriented Design patterns and Oracle Policy Automation. This article draws on the work and publications of Martin Fowler, which we discussed in the previous post, and those of Joshua Kerievsky from his highly regarded book “Refactoring to Patterns”.
Kerievsky makes two very important observations on design patterns. His first point is that, as he terms a section heading, “There are many ways to implement a pattern.” (Kerievsky, p. 26). This is key to what we shall see in this article, since with Oracle Policy Automation we should be aiming at implementing the core concept of a given design pattern, rather than strictly following the implementation example given in GoF (1995).
Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book describing software design patterns. It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice…The authors are often referred to as the Gang of Four (GoF) (Wikipedia).
The second key point that Kerievsky (p. 32) makes is that: “In general, pattern implementations ought to help remove duplicate code, simplify logic, communicate intention, and increase flexibility. However…people’s familiarity with patterns plays a major role in how they perceive patterns-based refactoring.” So we see here both our aims in using design patterns, and a constraint (developer knowledge). Since OPA does not have objects and classes in the same sense as an object-oriented language, we should not expect a straightforward application to OPA.
In this article we will focus on one single pattern, known as the Adapter pattern.
Summary: “Convert the interface of a class into another interface clients expect.
Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.” (GoF, p. 139)
Let’s look at applying the Adapter pattern to Oracle Policy Automation rules. At one level, translation is possible; Oracle Policy Automation can translate all its attributes into another language so that the rules can be used once and deployed in multiple languages just by translating the variables, statements, and similar features, while not rewriting the rules. This example from Oracle (2016) demonstrates this:
As a second example, we can make a variable equal to another variable, or a Boolean true if another Boolean is true. For example:
Here we have adapted the ‘the sky is blue’ to ‘the sun is shining’ (but not vice versa) and adapted ‘the value of the car’ to ‘the value of the vehicle’ (but not vice versa). It might be thought that this is pretty simplistic and not all that useful. The following example highlights more complexity, and, instead of simply adapting the interface, as the above examples do, it goes beyond that to override some of the adaptee’s behaviour:
Here we have adapted the interface from ‘the storey of the building’ to two different interfaces, ‘the lift floor’ and ‘the elevator floor’. British lifts start at 0 (or G) and US elevators start on the 1st floor and do not have a 13th floor. So not only have we changed the interface, we have adapted the behaviour. The new variables can be used elsewhere in the policy model in place of the original one.
Object-Oriented Design Patterns and Oracle Policy Automation : Adapter Pattern Summary
The Adapter pattern seems “made for OPA”. When discussing the Adapter pattern the GoF (p. 142) stress that:
“Adapters vary in the amount of work they do…There is a spectrum of possible work, from simple interface conversion – for example, changing the name of operations – to supporting an entirely different set of operations.”
The examples shown in this article illustrated three aspects:
- The first adapted the language that users would see
- The second was an example of changing the name of an operation
- The third supported a different operation but was also an Oracle Policy Automation-specific variant of what the GoF (1995) term “two-way adapters”, since it adapted two variables from one underlying one.
Each of the three examples has different costs and benefits. The language translation tightly couples the adaptee and adapter, while the changing of the name allows for the other variable to change how it is derived without changing the adapter (i.e., a level of indirection).
It is important to note that the one-way variable name change or Boolean name change simply allow a new term to be used, but these might very well be used in more complicated ways in rule tables (for variables) or rules (for a Boolean) where the adaptee’s value equalled the adapter’s value only in certain circumstances. The two-way adapter allowed for a single variable to be used to provide multiple adapters, thus minimizing code duplication.
The Bigger Picture
It’s worth stepping back at this point to understand the broader context. Computer science is often defined as dealing abstraction, and software engineering as managing complexity, and the connection is that only by considering different parts of programs and systems as abstract concepts are better able to manage complexity. For example, Oracle Policy Automation is often integrated with other systems that the Oracle Policy Automation developer does not need to understand, and can think of in the abstract, like the database that Oracle Policy Automation may interact, but which the Oracle Policy Automation developer may not need to know anything about beyond mapping attributes in Oracle Policy Automation.
So abstraction is about ignoring irrelevant details, and this is accomplished by what is often the theme running through many design patterns, which is to: “encapsulate the concept that varies” (GoF, p. 54). We often obtain abstraction in Oracle Policy Automation by using indirection (interposing an intermediate attribute) to encapsulate the attribute that varies. This allows us to “Program to an interface, not an implementation“, as the GoF (p. 18) term it, the rationale for which is that the implementation can be changed if other parts of the program only depend on the interface.
Once again, even from a very simple set of examples, it should be clear that Oracle Policy Automation rules will benefit from the targeted application of principles from programming – in this case Object-Oriented Patterns. The best approach is not a slavish application, rather a pragmatic use of those best-suited to the unique nature of the Oracle Policy Automation platform.
For more information about the ideas discussed in this article about Object-Oriented Design Patterns and Oracle Policy Automation, Dr Sender can be reached using his LinkedIn profile, below. Look out for more articles about Object-Oriented Design Patterns and Oracle Policy Automation coming soon!