Class ⇒ Code (Charlie Lima Alpha Sierra Sierra)

Are you fond of painting? There are multiple types of painting styles and techniques, each with their own characteristics. The same picture can be represented in multiple styles, and although the final product will be “the same”, the techniques inherent to each of those styles will make each of the versions distinct from each other. Some may evoke different feelings, some may highlight certain parts more than others, some may look different because of the physical properties of the paint. And, of course, some techniques may be better suited for certain goals than others.

“paint” flickr photo by Burntwood90 shared into the public domain using (CC0)

Once again, the topic for this entry will be class design. It’s actually pretty fun to come up with new analogies for the same thing over and over. And one more time, I’ll be taking UML class diagrams as my main reference for this post, so have that in mind.

As I’ve already stated in my modelling languages post, class diagrams are a way of graphically representing an Object-Oriented structure; they display behaviors and relations among classes, which is particularly useful for the design stage of development. After having designed all of our classes the ideal thing is to plan on how the system is going to be implemented, and that’s when we face a new issue: what language are we supposed to use for said implementation?

Just like painting and the different techniques that exist for it, programming has a similar relation with different programming languages. If we want to develop an application, there are tons of languages which we could use and objectively archive the program’s purpose. However, different languages have different characteristics, some may be more efficient regarding resources like time or memory, others could have functions that are better implemented for what is needed, others can simply be preferred by certain developers. Regardless, it’s important to determine what language would be more appropriate for some situations.

Let’s get the obvious out of the way. Classes by themselves are fundamental parts of object-oriented programming, so it’s much easier to implement class diagrams with a language that supports the object-oriented programming. The thing is that, even among this type of languages, we still have multiple options. Different object-oriented languages have different degrees of object orientation and, therefore, can adapt to different necessities. A few distinctions derived from these differences are the following:

  • “Pure” OOL, where everything is treated as an object. (Python, SmallTalk,…)
  • Languages designed for OOP that still have some procedural elements (Java, C++,…)
  • Procedural languages with some OO elements (PHP, MATLAB,…)

Regardless of which subclassification of OOL is chosen, the process of implementation will most likely be very easy. Class diagrams already define classes, methods and attributes, so translating that into any of the languages above is a simple task.

One thing that I’d like to point out is that a lot of the Object-Oriented Languages aren’t actually Object-Oriented exclusively. Many of them (most notably, the more popular ones, like Java, Python and C++) are actually multi-paradigm languages. This means that they support multiple programming paradigms and, that if OO is one of them, then they can implement class diagrams easily but also, even if not completely related to the class ⇒ code topic, adapt many other functionalities available from other paradigms.

Now, if we wanted to implement class diagrams (or any kind of OOP design for that matter) in a non-OOL it would not be an easy task. Practically every feature shown in OOP diagrams is proper to the object-oriented paradigm, so there wouldn’t be any support for the implementation of such diagrams as they’d be. There are ways in C, for instance, to manipulate and kind of achieve similar behaviors to those of OOP, but I’d rather recommend modifying diagrams to better fit the paradigm that’s available in certain languages, it’s probably easier and would take less time to complete.

Whether we decide to implement a diagram in an OOL or a non-OOL, design is key for a better outcome. There’s a reason for artists to do sketches, right? Deciding on what language to write code in is also a very important step for the development process, I’d say that sometimes the differences between one language or another are not that significant, but when specific necessities must be fulfilled, it’s the developer’s duty to correctly determine the best option for the code.

TL; DR: Don’t implement Object-Oriented Designs in a non-Object-Oriented Language.

Also, most of the information I got for this entry actually came from forums or opinions on different websites like this or this. I justify that decision in the second partial reflection!

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with
Get started
%d bloggers like this: