Although C# is a static programming language, with object programming (OP), extra behaviors can be added to objects at runtime. We now are a little closer to the ideal world – Static Typing Where Possible, Dynamic Typing When Needed.
What is Wrong with Static Typing
The most critics to static typing come from its rigidity and inflexibility to requirement changes. The rigidity and inflexibility is due to the lack of mechanism to alter objects at runtime. A class has to be defined at design time before an object can be created out of it and used. An object behaves as defined in its class, no more and no less. On the other hand, with dynamic typing, an object can be created without class and can be altered at runtime.
Even though we need to define a class to create an object in a static typing language, the situations can be alleviated if the object’s behaviors can be enhanced at runtime. That is what the object programming is about. With object programming, a set of behaviors are defined as methods based on business and system requirements. These behaviors are, then, attached to objects as needed in an application. At runtime, the attached behaviors are performed before and/or after the invocation of the object’s methods.
Class Programming and Object Programming
Class Programming (CP) is static typing programming. It is everything we do today with a static programming language: define classes, create objects of the classes and then use the objects.
On the other hand, the object programming (OP) is an answer to the critics on static typing’s rigidity and inflexibility. However, instead of altering an object like in dynamic typing languages, the object programming attaches extra behaviors to an object and returns a proxy of the object. To client of the object, the proxy is still the same type and is used as if it was the original object.
Now that we have two programming paradigms to choose, which one should we use and when to use it? Well, class programming is a code translation and abstraction of OOA/OOD. Since OOA/OOD are excellent for modeling business entities and business processes, the class programming excels at breaking a system down into business components and describing business processes through them. However, besides business requirements, a software system should also have other capabilities like logging, security, auditing, transaction management, etc. and adapt to requirement changes. These issues are not addressed by OOA/OOD, and therefore, cannot be solved effectively by class programming. That is why the object programming comes in handy. Since these issues are dynamic in nature, they can be translated into a set of methods and attached to objects at runtime. Therefore, in the software development life cycle (SDLC), the class programming can be used to define 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, the object programming can be used to address other issues and respond to requirement changes at runtime as needed.
With class programming, an application developer can expect a software component with core business functionality and well-defined client contract (interfaces). With object programming, the application developer can add extra functionality to objects of the component as needed at runtime. That is what we mean by “Class Programming Where Possible, Object Programming When Needed!”
Object programming is particularly suitable to address cross-cutting concerns and adaptive to changes of a software system. Please refer to OOP, AOP and OP to see how object programming addresses these issues. To see how an application can be enhanced with functionality like logging, security checking, transaction management and sorting using the object programming, please refer to Dynamic Object programming and Application Development With Component-Based Object Extender.
