Tag Archives: Smalltalk

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.

Smalltalk a world of living Objects

When I first discovered Smalltalk, it took me a while to get my head around the fact that in image based Smalltalk systems, source code is not written in flat files. Source code in files was so ingrained into my thinking, I had to unlearn and leave a lot of assumptions I have made. In most programming languages programs are written and defined using text files, typically source code is written in text files, using a text editor or an IDE such as Eclipse, IntelliJ or Visual Studio. At this point it just “dead code” in text files, there are no running objects, this is often referred to as compile time. Before a program runs, the runtime environment is created, the program’s source code is parsed, compiled and executed, and when the program finishes the runtime environment is destroyed, so in essence every time a change is made to source code the entire program is created from scratch. Smalltalk is pure object oriented and everything is an object and everything is achieved by sending messages to objects. In Smalltalk we dont use source code in text files to define programs (classes methods etc) instead objects are used to define Smalltalk programs, objects themselves are used to define new classes method etc. Now an object can exist only at runtime, and in Smalltalk everything happens on the fly, there is no such thing as compile time, Smalltalk is a runtime, it is not just a programming language, its a living system, it is a world of “living objects”. This requires a paradigm shift and it often is one of the biggest barriers I find people face when entering into the Smalltalk world. Smalltalk pushes “Object thinking” to another level, but once you push past that barrier you enjoy all the benefits of working with living objects, you can interact with objects, inspect them modify, extended and change them on the fly. This is the main reason why Smalltalk environment have such powerful IDE’s.

So what happens when the smalltalk VM is shut down or not running ? Do the objects then die ?

No. The objects are in a suspended state or go into hibernation and are stored in an image. This is analogous to a VMware image, when you close a vmware image the operating system goes into a suspended state, so the next time the vmware image is loaded to exactly the same state it was before. In Smalltalk objects essentially never die (note objects without any references will be garbage collected), they simply go into a suspended state in the image, in a Squeak Smalltalk image it is very likely some objects are probably 30 years old !

In Smalltalk everything is an object, classes are first class object too, so they can respond to messages just like any other object, so it trivial to create new classes on the fly. The image based system of the Smalltalk might be a stumbling block for people entering into the Smalltalk world but I think this is one of the main things that gives Smalltalk its power, its awesome IDE and the ability to work with live objects makes development so much more productive.

So Smalltalk code doesnt live in files so what happens to version control systems then ?

I do most of my Smalltalk development in Squeak and I use Monticello as the versioning system, in Smalltalk source code itself are represented as objects and are basically modelled as a collection of packages, classes, and methods. Code changes then simply become addition/removal or update of these elements. Since the entire source code are modelled in objects, Smalltalk version control systems have very powerful merge and diff algorithms. The version control systems are language aware and source code changes and history can be tracked down to individual method.

Smalltalk is an amazingly powerful environment, developing in a Smalltalk made me see what incremental development is really about. I guess with GemStone now working on a Ruby VM which is primarily based on the GemStone/S Smalltalk VM, folks from the Ruby world can also experience developing with living objects

My journey to Smalltalk

Ever since I started my professional career as a software developer back in 2002, nearly all of my development was done using C sharp and .NET framework with a bit of Java here and there. However while studying software engineering at University of Sydney 90% of my work was done on unix machines, I was taught object oriented programming in my first year, and thankfully we didn’t get introduced to OO by learning C++ or Java but a language called Blue (it was first developed by the Basser Computer Science department at the University of Sydney to teach students OO concepts) . Blue was not just a programming language but was a programming environment, which allowed interactive manipulation of classes and their relationship to each other graphically or textually. This allowed me to visualize a group of instantiated objects whose state was encapsulated and only way the objects performed anything was by collaborating with each other sending messages to each other to perform a task.

As I learned mainstream languages like C++ and Java. The idea of objects sending messages was blurred by multiple inheritance, classes and types. Throughout the years as I read books, researched and experimented with different ideas, I noticed Smalltalk being reference numerous times in every book OO book and every time Objects, XP and TDD were discussed. Xp and TDD were all conceived in the Smalltalk community and some of my favorite authors like Kent Beck, Rebecca Wriffs-Brock and the numerous speakers at OOPSLA every year all had a Smalltalk background. So about a year ago I decided to check out and learn this Smalltalk thing. It was a steep learning curve in the beginning (especially getting used to the idea of not working with source files) it was a big paradigm shift but it the best thing I did, there such a long history and wealth of experience in the Smalltalk community. Just browsing through code base in the standard squeak Smalltalk image, studying the wonderfully crafted code which was refined and polished by master Smalltalk craftsman over the last 25 years has improved my understanding of good OO design and also increased my productivity in my day job using C sharp and .NET. After experiencing Smalltalk and programming with “live objects”, going back to C sharp or java seems a little dull at times they are not nearly as expressive as Smalltalk. While learning squeak Smalltalk and as I immersed myself into the Smalltalk culture, I stumbled across Seaside a framework to create web based applications entirely in Smalltalk. Seaside kind of blew my mind, I have dabbled with Rails a bit and it is very clean and can be very productive, but Seaside takes web based development to a whole new level I never seen highly complex web based applications developed this way. Well it wasn’t long before I discovered GemStone/S which is not just an OO database but a powerful object server based on Smalltalk (more on this in another post). Through Smalltalk I rediscovered just how powerful it is to think in terms of objects not classes and just be able to send any message to *any* object that can understand that message. Now I realize that OO is more about message passing and actually very little to do with classes, inheritance or types. I found this quote by Allan Kay where he states what OO is all about.


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