The Technical Aptitude Required for Object-Oriented Programming
One of the primary purposes of an object-oriented programming language is to recreate representations of solutions to specific problems with code. These representations are transformations of solutions that were typically solved previously with human interactions.
Sometimes certain problems are solved only with the feat of modern computer software. In other facets, ingenuous minds forge an inventive technology in software not unlike the ways of the great mechanical inventors of our age.
Traditional object-oriented programming has been one of those great technical inventions. While simple guidelines allow most programmers to attempt object-oriented programming, only few understand the principles and practices to actually model real concepts correctly.
Frequently, programmers create objects that simply do not exist in the domain, or are bastardizations of the true domain concept. Unfortunately, in these scenarios success is short-lived. Maintainability quickly degrades, and often the code is completely thrown away.
Incorrect representations of the domain are similar to the adage of trying to fit a square peg into a round hole. Perhaps it’s possible to do this with creative technical feats. However, as more features are requested, as bugs are fixed, and the code evolves, misrepresentations are quickly revealed.
When this happens, feature requests and bug fixes take longer than expected, and a tremendous amount of pressure is put on the development team to meet deadlines. Managers and executives begin to wonder why it is taking so much time to complete what they think are smaller tasks.
All-nighters, pizza, and an insane amount of coffee support the developers through their death march. If you have been developing for a decent amount of time, I am sure you have told of such horror stories over lunch or over a good beer.
The Expressiveness of a Language Matters
How do we prevent this pain? There are several factors that contribute to these unfortunate events, however expressiveness within source code can be an important piece of the puzzle. The best developers are often the most expressive in the language he or she is operating in.
Instead of engineering solutions using technical wizardry and concepts that only programmers can understand, being expressive within the source code can keep business rules intact as development continues and solutions evolve.
Expressiveness is a quality that developers must constantly be working toward. Interestingly enough, the choice of a programming language can greatly assist in this struggle. The more expressive a language is, the easier it is for the programmer to think about the domain.
If non-programmer types and developers communicate with a ubiquitous language, this language can pervade into the source code. The pervasiveness of a domain’s language allows ideas to be more easily understood.
Contrasting Language Expressiveness
On May 30th, 2009, Scott Bellware gave a talk entitled, “A Handful of Things You Can Do in Ruby That Scares the Pants Off of C# Developers.” In this fascinating talk, Scott showed two functionally equivalent, plain classes: one defined in C#, the other defined in Ruby.
An interesting illustration emerged when Scott showed how the C# class’s definition comprised of a lot more statements to instruct the compiler on what to do and how to perform. These statements take the programmer’s mind away from the domain and bring him or her to thinking in a technical programming wonderland.
On the other hand, the Ruby class contained very little compiler instructions; the class was mostly comprised of domain expressions. This is a powerful illustration, so I’d like to show it as well as a means of illustrating expressiveness.
Let us define a simple class that records recommendations of businesses. Recommendations can be used for any business type, such as restaurants. A ‘recommender’ can recommend a business only once. The class will allow a means to determine how many recommendations all of the businesses have received.
The C++ Definition (brace yourself)
First, I will define the class using one of the most traditional object-oriented programming languages: C++. Let’s start as we always do with C++: with a header file definition:
This will define the basic contract that consuming code will use to work with the RecommendationTracker class. Pay particular attention to the usage of pointers, references, “constness”, and other statements used to tell the compiler what to do.
Now that we’ve declared the contract, lets look at the overly verbose definition of the class:
Once again, we have several statements regarding constant state of pointers, language like “it->second.size()”, which refers to the size of a vector that is the value portion of a map. Look at how the class name is repeated before each function definition; this tells the compiler what scope we are in.
Although not appearing in this example, frequently C++ programmers have to tell the compiler whether they want to allocate objects’ memory on the stack or heap, and have to manage the lifetime of that memory.
All of these intrinsic C++ concepts force the programmer to be very technical. Much time is spent on considering the language itself rather than the domain.
The C# Definition (a little better)
Now lets port this same class to C#. C# is a bit more modern than C++, slightly more functional, and isn’t so concerned about telling the compiler what to do.
One slight problem: since there is no easy way to return a list of pairs as in the C++ definition, I’ve created a small helper class called “RecommendationTotal.” I could have returned a dictionary, but the usage of a dictionary in C# usually suggests something other than name/value pairs:
Some may argue that this adds readability to the code; for C#, it probably does. Now, the definition of the RecommendationTracker class is as follows:
It’s nice that the declaration and definition are now combined into one, and we don’t have to deal with header files anymore. However, there are still many references to compiler instructions.
Every method must tell the compiler whether it should make the method public or private. There are several references to types, such as “IEnumerable<RecommendationTotal>” and “IDictionary<string, ICollection<string>>.”
These compiler instructions and type declarations take our minds away from thinking about the business and have us spend more time on thinking about programming.
The Ruby Definition
Now let’s look at the same code in Ruby:
1: class RecommendationTracker2: def add_recommendation(recommender, business)3: has_recommender_recommended_business?(recommender, business) do4: raise StandardError, 'You may only recommend the same business once.'5: end6:7: @recommendations[business] << recommender8: end9:10: def recommendation_totals11: recommendation_totals = Hash.new12:13: @recommendations.each_key do |business|14: recommendation_totals[business] = @recommendations[business].length15: end16:17: recommendation_totals18: end19:20: private21: def initialize22: @recommendations = Hash.new do |recommendations, business|23: recommendations[business] = Array.new24: end25: end26:27: def has_recommender_recommended_business?(recommender, business)28: return false if !@recommendations.has_key? business29: return false if !@recommendations[business].include?(recommender)30:31: yield32: true33: end34: end
Notice how concise the Ruby definition is? Compiler instructions are kept to a minimum, and the statements seems to emphasize the logic of the domain more. Furthermore, all unnecessary references to types have been removed.
Simple one line boolean statements have been rearranged in a “action if condition” format instead of “if action then condition.” Methods have a question mark to add to readability. Overall, the code is simply a lot more expressive.
Contrast the Ruby definition to the original C++ definition. We’ve come a long way haven’t we? What’s frightening is to think that Ruby was created in 1992! For some reason, it’s only recent that it has been receiving a lot of attention (probably due to Rails and the direction of software toward web platforms).
C++ is still a great language, and has its place within specific industries. Game development is still primarily performed in C++, mainly due to the performance requirements where every bit of speed must be squeezed out of the code.
C++ is definitely a professional programming language, and requires the programmer to understand the power it can provide. A high degree of technical aptitude is required to create concrete, easy to understand, scalable, and powerful applications in C++. Unfortunately, it also takes more time.
However, instead of focusing on technical aptitude, developers should focus on adding value to the domain they are developing for. This means most thought should be spent thinking about how best to express the core domain, where all of the business rules and logic should reside.
Compiler instructions and nifty technical tricks are cool, but they take time away from adding to the core domain. As Eric Evans has illustrated, the easiest way to determine the core domain is ask why is the development effort important? How will the code you are writing help the business compete?
The answer to those questions should point you straight to the core domain. Expressiveness allows developers to define the core domain with a refined eloquence that helps lead to a deeper understanding of the problems at hand.
If source code is less infected with technical concepts, true domain problems are more easily read. This greatly adds to maintainability, and allows object-oriented principles to be practiced more easily.
I am excited to see more developers diving into Ruby. Hopefully, as the community becomes even more established than it already is, we will all start creating more elegant designs and expressions of problems without focusing too much on telling the compiler what to do.
This entry was posted on Saturday, June 6, 2009 at 8:58 PM and is filed under c#, C++, DDD, elegance, expressiveness, philosophy, ruby. You can follow any responses to this entry through the RSS 2.0. You can leave a response.