Tag Archives: Object Oriented Design

Why GemStone/S

Most business software systems are built using the object oriented paradigm, one of the key concepts of OO is encapsulation and that the data and behavior be packaged together and the distinction between the two be hidden within the object. In every company and client i have worked for one of the biggest assumptions made is the idea that programs and data should be stored separately, storing data separately violates encapsulation at the most fundamental level and it greatly limits the adaptivity of a system. we aren’t able to completely leverage all the benefits of Object Orientation.

“However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.” – Alan Kay

Now to eliminate the distinction between databases and programs, we need a technology that seamlessly integrates the capabilities of the programs and storage and multi user capabilities of databases. This is exactly what GemStone/S is, its a Smalltalk dialect, that has object persistance and transactional capabilities baked into the Virtual Machine !. A GemStone/S repository has living objects (there is no seperation between code and data, Code are objects too). GemStone/S is not simply an object oriented database because it not only can stores objects but also can execute them in a muti-user environment. What GemStone/S is, is its a true object server.

So what does this buy us ?

  • No more object-relational mapping (no need for ActiveRecord, Hibernate, GLORP like ORM’s)
  • Makes the software incredibly adaptable, normally if we change the structure of the data defined in a class, we would also need to modify the structure of the database, mapping files etc to reflect the change, so GemStone/S Eliminates need for the synchronization of code and data, because there is no distinction between the two.
  • Objects can evolve as the business needs change, Its quite simply to change the shape of a class in a GemStone/s repository.
  • Allows us the ability to create executable business models and objects that cross cut applications, so pure objects can be shared across mutiple applications. The object can expose a specific interface with a set of messages to each application. This way there is a single point of reference for a particular object and also a single point chage for a particular object. (note none of the data is ever exposed to the app, every thing is done through the object interface by sending messages)
  • Check out this case study where a large shipping company used GemStone/Smalltalk to create a pure OO solution.

Object Oriented or Class Oriented Design?

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.

Object Thinking

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

Class Diagram

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

Implemetation Using Object Composition

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