This is an overview of the terms I found to be useful for OO design. That doesn’t mean other terms are not important, but for starting OO design, you could focus on these terms.

Software Architecture layers and Class Categories

• Presentation layer
  • Application
  • Controller
  • View
  • Model
• Service layer (= Interface layer)
  • Server proxy
  • Client proxy
• Business layer
  • Business Object
  • Business Object Factory
  • Sub Business Object
  • Workflow object
  • Process object
  • Workflow Business Object wrapper
  • Converter object
  • Utility object
  • Data Provider object
• Persistence layer
  • Data Access object
• Database layer
  • Queries
  • Database tables
• Others
  • Formatter
  • Converter
  • Utility

OO terms

• Entity
• Object = Entity + Behavior + Instantiation
• Object behavior
• Object instance
• Class = Entity + Behavior
• Class definition
• Class implementation
• Class interface
• Relations
  • Parent / child relation (composition / association)
  • Super class / sub class relation / Class interface
• Business Object = Objects for the Business like Sales order, Customer and Material
• Entity = Real world object about which you are storing data

Object Oriented Principles (OOP)

• Object instantiation
• Encapsulation / data hiding
• Inheritance / Generalization / Specialization
  • Super to Sub class relationship
  • Override / redefine
  • Polymorphism
• Realization (class interface)
  • Class Interface to Implementing class relationship
• Parent / child relations
  • Composition / Aggregation (Sales order head –> Sales order item)
    • Parent to Child relationship
  • Association (Sales order item –> Material)
    • Associating to Associated class relationship
    • Client to Server class relationship
  • Dependency
    • Consumer to Provider class relationship
  • Cardinality
• Abstraction / Class interface

Other basic programming principles

• DRY = Do Not Repeat Yourself
  Don’t copy code within the same system. Always try to reuse it.
• KISS = Keep It Simple and Stupid.
  Don’t overdo creating classes. For example when an iterator class is not needed, because a LOOP AT works fine, than do not create an iterator class.
• Clean ABAP
  Contains many rules for clean code.

Appendix: SOLID principles

S – Single Responsibility Principle

Class is responsible for one job or purpose.

• A BO class is responsible for one Business Object instance
• A BO factory is responsible for instantiating for class and it’s sub classes.
• A view class is responsible for one view.
  • A view can contain more views. But those child views are responsible for them selves
• A BO data provider class is responsible for reading data of one Business Object instance.
  For example only for Sales Orders.
• A BO list data provider class is only responsible for reading lists for one business object type. For example only for Sales Orders.

O – Open for extension and closed for modifications

A class is Open for extension but Closed for modification.

• Modification = changing the class public section interface.
  Changing class name, changing method name, parameter name, changing parameter type, public data type.
• Extension =
  • Adding a class
  • extending the class public section interface.
    • Adding a method, an optional method parameter.
    • Adding / changing method implementation, protected and private properties and data types.

L – Liskov Principle

Every subclass or interface implementing class should be substitutable by its super class or class interface. When using static types in method parameters, this is enforced by SAP syntax check. In a language which has no strict typing, like JavaScript, returning a different data type is possible.

I – Interface Segregation Principle

If an interface class or a super class has methods which the implementing / sub class must implement, but does not need, than it should not be in the interface class or in the super class.

The solution for this problem might be refactoring:

• splitting the interface class in multiple interface classes
• pulling the not needed methods of of the super class and placing it in a separate interface class.

D – Dependency Inversion Principle

Entities must depend on abstractions (=Class interface or Super class), not on concretions.

When a client class uses a dependent class, and this dependent class is very specific, for example a Internal Sales Order, than the client class is not allowed to use a reference to class name “Internal Sales Order”, but it must use a more generic class or interface class, so that it is more flexible for the future so it can also other Sales Orders types, than only the Internal Sales Order.

The solution for this problem might be refactoring:

• Realization generalization: create an interface class
• Inheritance generalization: create an abstract super class

UML diagrams

• Most important
  • Class diagram
• Could also be used but harder to maintain manually
  • Sequence diagram
  • Package diagram
• And more, which I don’t use.
  • …

Patterns

There are many design patterns and it is hard to remember and use them all.

I don’t use many patterns, but some are very important to me.

If you really want to studie more design patterns, which is a good choice, than the design patterns of “The Gang of Four” is a good starting point. See Wiki.

Presentation layer

• MVC model
• Proxy

Creational patterns

• Constructor method (is not a pattern)
• Static factory method (is not a pattern)
• Abstract factory
• Factory method
• Singleton

Structural patterns

• Facade
  • In case of a complex Server object with many sub objects,
    the Server object calls all the sub objects.
  • The Client object calls only the root Server object.
• Proxy
  • Is a surrogate class / wrapper class for an another class
  • Types:
    • Remote proxy – intent is calling remote logic
    • Virtual proxy
    • Protection proxy
  • ABAP examples: XI-SOAP Client ABAP Proxy / Server Proxy and OData Proxy class
• Adapter

Behavioral patterns

• Observer (= eventing)
• Strategy

And there many more, see for more patterns see Wiki – Software Design Patterns.

And for some fun and educational videos about patterns see Christopher Okhravi.

Anti-patterns

• God object
• Object orgy
• Sequential coupling
• Yo-yo problem
• Arrow pattern

And there many more…

Important OO related topics

• TDD – Test Driven Development (Test First Development)
  • ABAP unit
  • Test doubles