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!”

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.