Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Class Programming Where Possible, Object Programming When Needed

, 25 Dec 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
Discuss unifying static programming and dynamic programming in application development

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 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 response 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.


License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Gary H Guo

United States United States
Object-oriented (OO) is about "classes" not "objects". But I truly believe that "objects" deserve more our attentions. If you agree, read more on... Dynamic Object Programming (DOP), Component-Based Object Extender (CBO Extender), AOP Container and Dynamic Decorator Pattern.
 
Mobile development is not just another type of front end. The real challenge is actually in the back end: How to present meaningful information in time to mobile users with exponentially increased data flooding around? Here is my first mobile solution: SmartBars - Barcode Reader, Price Comparison and Coupons.
 
Gary lives in southeast Michigan. My first programming language is FORTRAN. For the last a few years, I have primarily focused on .NET technologies with Mobile Development as my newest interest.

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.1411023.1 | Last Updated 25 Dec 2011
Article Copyright 2011 by Gary H Guo
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid