OOP, AOP and OP

As everybody knows, OOP stands for object-oriented programming while AOP stands for aspect-oriented programming. But what is OP and why put it together with OOP and AOP? In short, OP stands for object programming. Let me give some brief descriptions for each of them first.

OOP

Object-oriented programming (OOP) is a programming paradigm using “classes” – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. It excels when it comes to breaking a system down into business components and describing business processes through them. Over the software development life cycle (SDLC), it follows a set of design principles and uses inheritance, composition and design patterns to evolve a software system. The primary efforts are design of classes based on business requirements while abiding by the principles and applying the design patterns properly.

Design patterns are often employed to solve common problems in software design for a complicated system. On the other hand, the application of design patterns makes the system more complicated. The other weakness of OOP is its inability to address cross-cutting concerns.

AOP

Aspect-oriented programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. It tries to address the weakness of the OOP for cross-cutting concerns. However, the AOP is still immature and not widely adopted. It is still lack of principles or patterns to follow for addressing cross-cutting concerns of a software system.

Today, most AOP tools separate cross-cutting concerns into modules and then injet or weave the modules into classes. It is ironical that in OOP we try everything possible to decouple software entities into components so that we can have a loosely-coupled and therefore more flexible system, then, in AOP we modify the components with the code of cross-cutting concerns and end up with a tightly-coupled and inflexible system. This is less elegant. And the more serious issue is the inflexibility. Once a cross-cutting code is injected in a component, there is no easy way to turn it off. More discussions about this can be found in the article Aspects to Object vs. Aspects to Class

OP

Object programming (OP) is a programming paradigm which aims to improve software development life cycle by extending objects at runtime instead of extending classes at design time. It complements object-oriented programming by avoiding changing or creating classes, and therefore, improves the flexiblity of a software system and reduces the system maintenance cost.

With object programming, a set of behaviors are defined as methods based on business and system requirements. These behaviors are, then, attached to object’s methods as needed in an application. At runtime, the attached behaviors are performed before and/or after the invocation of the object’s methods.

Object programming does not distinguish between business concerns and cross-cutting concerns. To it, all concerns are methods. A method corresponding to a cross-cutting concern may be applied to objects, either of the same type or of different types, at different places, while a method corresponding to a business concern is more likely to be applied to objects of a particular type at a specific place.

Object programming does not alter components in any way. Instead, it alters the client of components by attaching behaviors to objects of components right before they are consumed.

Object programming is flexible in a way that methods can be attached to objects as needed, which means you can use an object as is or add extra behaviors to it.

Object Programming with CBO Extender

Component-Based Object Extender (CBO Extender), as an object extensibility framework in .NET, is particularly suitable for object programming. With CBO Extender, you define a set of aspect methods to represent behaviors based on your business or system requirements. Then, you can attach the methods to objects as needed in your application. CBO Extender uses programming to interface, therefore, can only be used to add extra functionality to interface methods.

Let’s write a Hello World! application using CBO Extender. Say, you have a DoAnything class that implements an IDoAnything interface. The application code is listed as follows:

namespace HelloWorld
{
    public interface IDoAnything
    {
        void DoThing();
    }

    public class DoAnything : IDoAnything
    {
        public void DoThing()
        {
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IDoAnything doAThing = new DoAnything();

            doAThing.DoThing();
        }
    }
}

Of course, the DoThing method of doAThing object does nothing. Now, let’s define a SayHello method and a SayBye method, and use ObjectProxyFactory.CreateProxy2 method of CBO Extender to add them to the doAThing object as extra behaviors. The application is listed as follows:

using CBOExtender;

namespace HelloWorld
{
    public interface IDoAnything
    {
        void DoThing();
    }

    public class DoAnything : IDoAnything
    {
        public void DoThing()
        {
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IDoAnything doAThing = new DoAnything();

            doAThing = ObjectProxyFactory.CreateProxy2<IDoAnything>(
                doAThing,
                new string[] { "DoThing" },
                new Decoration2(SayHello, null),
                new Decoration2(SayBye, null)
            );

            doAThing.DoThing();
        }

        public static void SayHello(AspectContext2 ctx, dynamic parameters)
        {
            System.Console.WriteLine("Hello World!");
        }

        public static void SayBye(AspectContext2 ctx, dynamic parameters)
        {
            System.Console.WriteLine("Bye!");
        }
    }
}

Now, the DoThing method of doAThing object outputs the “Hello World!” and “Bye!”.

Actually, there is nothing that can stop you from putting any logic into the SayHello method or SayBye method. Your DoAnything component indeed can do anything! To see how the CBO Extender is used to add functionality like logging, security checking, transaction management and sorting, etc, please check with the articles Dynamic Object Programming and Application Development With Component-Based Object Extender.

OOP, OP and SDLC

Can you build a real world business system from the DoAnything component using object programming? Maybe. But it may need a set of new principles and some disciplines to follow so that your system is understandable and maintainable.

In the software development life cycle (SDLC), the OOP can be used to break a system down into business components and simulate business processes through them. It should be very clear that business components should only implement business logic and avoid change once released. Then, OP can be employed to address cross-cutting concerns and alter the system as needed. OOP + OP produces a less complicated, loosely-coupled and flexible software system.