Starting from Scratch: What Is Object-Oriented Programming?

It’s always interesting to learn about someone’s first experience at Smalltalk programming, especially when it’s their first experience. The following is an account of how Jeremy Jordan, the Marketing Manager for Cincom Smalltalk, discovered that something that once seemed complex is actually quite simple.

Recently, I had an opportunity to try my hand at programming in Smalltalk, specifically using Cincom ObjectStudio. I’ve never programmed in my life, so this opportunity was both exciting and intimidating. The excitement came with trying something new, having a challenge and seeing what I could figure out. The intimidation came from the fact that programming never really made sense to me. Sure, I understood that a programming language communicates with applications and devices, telling them what to do and how to do it. The practice of programming seemed daunting to me, however. Learning syntax and how to write the actual code in the correct order to make something functional seemed like something in a foreign language … literally! 

Thankfully, one of our Cincom Smalltalk engineers recommended that I read the Smalltalk User Guide found in Cincom ObjectStudio. As I began reading through some of the document, the introduction alone was a game-changer to me. After reading through some of the introductory comments, I finally understood what object-oriented programming represented, at least from a high level. Although this may be second nature to the Cincom Smalltalk product team, I would like to share some snippets of what I learned.

“I made up the term object-oriented. …” – Alan Kay

Daily, I see things on social media that are related to object-oriented programming such as inheritance, polymorphism, abstraction, encapsulation, dynamic binding, garbage collection and so on. These core object-oriented ideas, developed decades ago, are still influential concepts today.

Object-orientation is simply a way of thinking about
and modeling the real world.

That phrase was very intriguing to me and helped me understand why our product team talks the way they do and shares the types of demonstrations they do in team meetings.  Every application shared in a meeting or even publicly on social media and our website (think, the Hidden Gems screencast series) relates to something in the real world! Now we know why.

With Object-Oriented Programming (OOP), users are learning a programming language and a new way of thinking. When learning a new language of any kind, Linguist.com says, “You need to experience a language through lots of exposure before you can hope to learn it.” The same is true for object-oriented programming. The best way to learn OOP is to learn by immersing yourself in an environment, like Smalltalk, where you use objects all of the time.

In the object-oriented view of programming, standard computing concepts and data structures, such as control-of-flow, are abstracted and handled differently.

Instead, OOP focuses on simulating the real world.

There’s that phrase again … “the real world.” A developer uses objects to model real-world entities. Each object is intelligent and knows how to interact with other objects. With this approach, program design becomes relatively easy, because there is a direct correspondence between an object and its real-world counterpart, and you can bring all your real-world knowledge to bear. In fact, this approach allows you to focus more on the problem domain and less on computing-environment issues, such as memory management.

Marketers, like me, often look for “buzzwords” and “trends” to market a product, but object-oriented programming is a way of thinking, not a set of buzzwords:

• An object is a combination of instance variables that describe the object’s data, and methods that describe the object’s behavior. In other languages, variables are comparable in certain respects to attributes, and methods are analogous to procedures.
• Objects are intelligent—you can anthropomorphize (attribute human characteristics or behavior to them).
• To request data or an action from an object, you must send a message to it. If the object understands the message, it activates the appropriate method. So, objects communicate similarly to humans!
• The internal data elements of an object are not directly available to other objects. Other objects must always use messages to ask the object for its data. This is called encapsulation.
• How an object interacts with the outside world is called its behavior. The object’s tasks and responsibilities determine its behavior. Sometimes an object will delegate a task to another object to avoid having to remember too much. A distributed design using responsibility and delegation is a good way of dealing with complexity and is one of the hallmarks of an object-oriented approach.
• When designing an object, a developer concentrates on its behavior and interaction with other objects, not on its internal structure.
• An object-oriented system consists of a group of objects sending messages to each other. 

In summary, I learned that a good object-oriented design is based on the real world. Objects map to entities in the real world. An object-oriented system is thus a simulation of some aspect of the world. Sounds like an easier approach to something that seemed so complex to me. Now, how can we apply this?