Its been over 40 years since object orentation as a programming pradigm started in Norway when Kristen Nygaard and Ole-Johan Dahl invented the language Simula . Now a days most software is describe their work using some sort of object vocabulary and or use an OO language. However the ubiquity of object oriented languages does not mean, in experience most developers aren’t getting the full leverage out of object technology. Object orientation is a programming paradigm you can design object oriented software and implement it using almost any programming language, of course some languages offer you more support than others, conversly you can implement your software with a very non object oriented implemetation using an ‘Object Oriented Language’ such C#, Java or even Smalltalk. Object oriented design and object thinking trancends programming languages. So it not the tools or programming language you use to implement the software, but its the way you think about a design. Thinking in objects is the key to leveraging the most out of object technology to create elegantly designed software. Trygve Reenskuag creator of the MVC pattern, and the creator of the OORAM software Engineering Method comments that programming languages are class oriented rather than object oriented, thats why most of us end up thinking and modelling in terms of classes rather than objects. A Class is powerful abstraction to implement objects, but its inadequate for modelling and thinking about objects, because a Class is static, it is defined at build time, objects on the other hand are dynamic.
Objects vs Classes
It’s important to understand the difference between a class and an objects, I remember when I was at university learning C++ people used the term class and objects interchagably, it is key to distintguish between the two. A class can be viewed as template that defines a set of characteristics and behaviours an object will have, a class is also a factory which creates specific instances of objects that have these general characteristics and behaviours. In languages like Smalltalk a class is an object, that is responsible for creating instances of objects with a particular class of behaviours and charateristics.
Similarly it is important to distinguish between ‘Object thinking’ and ‘Class thinking’ when desgning Object Oriented software. Thinking and modelling a solution to a problem by thinking in terms of various classes rather than thinking of a group of objects working together, more often that not results in a implementation that is inelegant and rigid.
David West has written an excellent book titled “Object Thinking” (I highly recommend this book to every developer). Thinking in terms of classes, focuses our attention on the solution space rather than the problem space. A class is very static by thinking in terms of classes our solution tends to be static and rigid, objects on the other hand are dynamic, by thinking in Objects we let the problem define our solution, which leads to modelling a more natural and elegant solution. Think about an object as “A virtual person that is capable of performing certain tasks. who has access to all the knowledge and resources required to complete its assigned tasks”. What we will have is a cooperating community of virtual persons interacting with each other to solve a problem. Thinking in terms of objects will lead to a closer match between your object model and the business model (the enterprise domain). Thinking in objects also helps us find the naturally occurring divisions and classifications in the problem space.
Consider the following example, there is a Club that has different types of members, GoldMember, SilverMember and StandardMember, all members have a name, address, date of birth etc, but each type of member has a different discount Rate.
thinking in terms of classes we usually come up with the following implementation, using class inheritance
The above is a workable solution, but its kind of rigid. Suppose we have an object which is an instance of class SilverMember, think back to the ‘Object as a Person’ metaphor. suppose this virtual person (ie this object which is instance of SilverMember) wants to upgrade to a gold membership. What happends now ? with the above implementation you would have to create a new instance of class GoldMember. Class are static defined at build time, objects on the other had are dynamic, that is why it is important to think in terms of objects and the various Roles they play when modelling. In the real world all you would do is get a new gold membership card or something like that.
thinking along these lines we could come up with the following implemetation
in this implementation we have a solution that uses object composition, a member object has a Membership object. In the above solution it trival to plugin different membership objects into the member object. so if a SliverMember wants to upgrade to a GoldMembership all we do is set member Objects membership property to an instance of GoldMemberShip and discard its old SiverMembership.
The above solution is example of the strategy pattern in action. Thinking in terms of objects and modelling in terms of the Roles the objects play, leads to a elegant solution.
To conclude object orientation is a pradigm, its a way of thinking. A Class is great and a powerful abstraction for the implementation of objects, so most OO programming languages are class oriented because they are all about implemention of computer programs. But for modelling and designing object oriented solutions it is important we think in term of objects and the Roles the objects play. Trygve Reenskaug has written numerous articles and an excellent book on role modelling