Image source: Unspash
We’ve talked about the importance of software design and how avoiding the “code snippet collection” trap is crucial for building robust applications. Now, let’s dive into a core concept that underpins effective software design: object-oriented programming (OOP). Understanding OOP, even at a basic level, is incredibly beneficial for new developers. It’s not just about using an “object-oriented language” – it’s a way of thinking about software.
Learning to See the World as Objects
From the moment we’re born, we start learning about the world by recognizing objects. An object is simply a “thing” in our environment that we can identify, that has certain properties, and that behaves in a predictable way. Think about a toddler encountering the family cat. The cat is an object. It’s furry (property), has four legs (property), makes a “meow” sound (behavior), and likes to rub against things (behavior). If you pull its tail, it might scratch (behavior – a less desirable one!). The family might have multiple cats – different sizes, different colors, but they all mostly behave the same way. We learn to categorize them as “cats” and anticipate their properties and behaviors. A dog, on the other hand, is a different kind of object, with its own set of properties and behaviors.
This ability to recognize objects, classify them, and predict how they’ll behave is fundamental to how we understand the world. And it’s also the core idea behind object-oriented programming.
Object-Oriented Programming: A Simple Idea with Powerful Consequences
Object-oriented programming takes this natural way of thinking and applies it to software development. Instead of just writing lines of code, we organize our programs around objects, just like we organize our understanding of the world around objects. These software objects have properties (data) and behaviors (methods – functions that do things).
One of the beautiful things about object-oriented languages is that their syntax can be surprisingly simple and intuitive. Take Smalltalk, for example. Smalltalk is one of the earliest object-oriented programming languages, created way back in the 1970s, and it’s still used today for educational purposes and even some commercial projects.
The amazing thing about Smalltalk is its simplicity. The entire syntax of the language can fit on a postcard! Think about that – a whole programming language described on a tiny piece of paper. This simplicity makes it an excellent tool for learning the fundamental concepts of OOP. The Smalltalk environment itself is also object-oriented – the operating system, the development tools, everything is represented as objects. This purity makes it easier to understand how everything connects.
(Important Note: I’m not suggesting you learn Smalltalk! I’m using it as an example of how elegant and simple a pure object-oriented language can be.)
If you want a thorough explanation of the syntax and usage, well, that takes two whole pages: http://files.pharo.org/media/pharoCheatSheet.pdf. There is a 29 post-card live tutorial named ProfStef. Introductory video. Live tutorial.
For a more thorough discussion on object oriented languages and Smalltalk see this article : Are There Purely Object Oriented Languages?
Pure Object-Oriented Languages vs. Languages that “Support Objects”
Smalltalk is considered a “pure” object-oriented language. This means that everything in Smalltalk is an object. Other languages, like JavaScript, support objects, but they aren’t purely object-oriented. There’s a subtle but important difference. JavaScript has some object-oriented features, but it also has other elements that aren’t objects. This can make things a bit more complex. It’s a topic of much debate in the programming world, but for our purposes, the key takeaway is that the object-oriented paradigm – the way of thinking about software as objects – is valuable regardless of whether you’re using a “pure” object-oriented language or one that just “supports” objects. I won’t wade into the open and endless debate but instead, refer you to this StackOverflow thread. You can apply object-oriented design principles even when working with JavaScript.
The Benefits of Object-Oriented Design
Why bother with object-oriented design at all? What are the benefits? Here are a few:
- Modularity: Objects are self-contained units. This makes it easier to organize your code and break down complex problems into smaller, more manageable pieces. Think of it like building with LEGO bricks – each brick is an object, and you can combine them in different ways to create larger structures.
- Reusability: Once you’ve created an object, you can reuse it in other parts of your program or even in other projects. This saves you time and effort. Imagine you create a “button” object for your website. You can reuse that same button object on multiple pages without having to rewrite the code.
- Maintainability: Because objects are self-contained, it’s easier to make changes without affecting other parts of the system. If you need to update the behavior of a button, you only need to change the code within the button object, not the code for every page that uses the button.
- Abstraction: Objects allow you to hide the complex details of how something works and just focus on what it does. You don’t need to know how a car’s engine works to drive the car – you just need to know how to use the steering wheel, pedals, and gear shift. Similarly, in object-oriented programming, you can use an object without needing to know the intricate details of its implementation.
Object-Oriented design
I will discuss two OO design techniques that are relevant to this site and its training for beginning developers: Unified Modeling Language and CRC. UML is a very powerful visually oriented way of describing a design. I am a visual learner. For me a picture is worth way more than a thousand words. If I have to read a design description, I will get a piece of paper, and diagram what I am reading. With a diagram you can actually point your finger at things and trace their relationships to other things. There are people that can describe complex things in words in very vivid terms. Richard Feynman is perhaps one of the best. He has a series of lectures to ordinary college classes in which he describes Quantum Mechanics (which he was the major contributor to) in ways that make me say “OH! I get it now.”. But, he was a very brilliant and gifted professor. Most engineers can’t describe designs like that.
Introducing CRC Cards and UML
Now that you understand the basic principles of object-oriented design, you might be wondering how to actually apply these principles when planning your projects. There are several tools and techniques that can help, two of which are particularly useful for beginners: CRC cards and UML. CRC cards are a simple, low-tech way to brainstorm and explore the relationships between objects. UML (Unified Modeling Language) is a more powerful and visual language for describing software designs. We’ll explore both of these in more detail in the upcoming articles.
For full disclosure:
I am a HUGE proponent of the use of UML. I used it extensively during my career
at SAS Institute. I was one of the employees that was part of the origins of the formalized use of metadata. Metadata is a fancy term for information about data. One of the simplest forms of metadata is the filesystem on your computer. You create a directory called a Git repository. Inside the repository you create files. The files have names like README.md and index.html. The name tells you generally what it represents and the file extension tells you the language and the program needed to edit or present it (eg. .md for markdown, .html you can edit in a text program or a programming IDE, and you run it in a web browser. Other metadata is the date and time the file was modified, its size, and more.
The original metadata database for SAS products was written for a single specific project. It was called the “Metabase” (Metadata database) written in a SAS proprietary object-oriented language called SCL (Screen Control Language). It was written by one guy while flat on his back in the hospital after back surgery. He knew the details of how data and programs were described in our products and wrote SCL code to model that. If the details changed he would have to go back into the SCL and modify it to match. Since this was a fairly simple model, that was not too much effort.
However, when it was decided that all metadata for all SAS’ many products would be incorporated into a single metadata model, it was quite a huge task. See the product documentation of the metadata model. There are 172 different data types described. My team’s job was to implement a metadata server that would provide access to the storage of all of that metadata for all 300+ SAS products. Those products were growing and changing constantly. To implement all of that by hand coding classes was a monstrous job that would have taken a large team years to implement and maintained.
I thought there was a better way. I attended a software development conference called SD2000 in San Jose, California (where I went to university). Several of the presenters were the pioneers in the latest software development methodologies and technologies. I took what I learned there and came back to work. I pitched the idea of using the UML language and the applications to build and manage the model
as a tool. One of our team members learned to used those modeling tools, and her job was to visit with the development teams for all SAS products. She learned what metadata they needed to to make their product work and built a standardized model that unified all metadata for all those products.
Meanwhile, I wrote a program called ModelCompiler (in Java) which would read in that model from the tools and generate C source code to implement the model in the
metadata server that our team built. That code was compiled and linked into our products so that they could access the server. By the way, the product documentation shown in the link above for the SAS metadata model is also generated using the UML model.
Even though the most visible part of a UML model is the diagrams, the underlying model that describes all of those details is stored in a rich database. The diagrams are drawn automatically using drawing algorithms. There is also text and lists and lots of other representations. Since the model is a live database, it is possible to write programs that navigate through the details in that database and generate almost any kind of representation, including source code, and HTML diagrams.
What have you learned?
Think about a recent coding project you worked on, even a small one. Can you identify some of the objects involved? What are their properties and behaviors? Share your thoughts in the comments below!
What’s next?
Now that we’ve explored the importance of object-oriented design and the benefits it brings, we’ll delve into how to apply it using CRC cards. This simple technique will help you start thinking in objects and lay a solid foundation for your software design process. Click here to continue to the next article: Designing with Objects: An Introduction to CRC Cards.
This article complements the first one by providing a concrete solution to the problems previously discussed.
The first article highlights the issues associated with using isolated code fragments (code snippet collection) and explains why this approach leads to fragile applications that are difficult to maintain and evolve. It introduces the idea that software design is essential for creating robust applications.
This second article expands on that idea by presenting Object-Oriented Programming (OOP) as a software design method that allows code to be organized in a structured and modular way. OOP is presented as a solution to avoid the pitfalls of fragmented code.
Thus, the second article answers the question “How to do software design?” by introducing OOP as a key approach.
I share my understanding in four (4) key points:
1. Understanding the World as Objects
Through a simple and effective analogy, the article explains how we have always learned to identify and classify objects in our environment based on their properties and behaviors. This way of thinking in terms of objects is fundamental to Object-Oriented Programming because it allows software to be organized in an intuitive and natural manner.
2. What is Object-Oriented Programming (OOP)?
The article explains that OOP consists of structuring a program into objects that have data (properties) and behaviors (methods). The goal is to organize code just like in real life—with entities that interact with each other.
The article emphasizes understanding the principles behind object-oriented design, giving the example of Smalltalk. While learning Smalltalk itself is not essential, the key takeaway is grasping object-oriented concepts. The article also differentiates between purely object-oriented languages and those that simply support objects.
3. Why Use Object-Oriented Design?
The article presents several benefits of Object-Oriented Design:
Modularity: Code is organized into independent units, making project management easier.
Reusability: An object can be reused in other parts of the program or even in other projects.
Maintainability: Changes can be made more easily without breaking the entire system.
Abstraction: One can use an object without needing to know all its internal details (e.g., driving a car without understanding the engine).
4. Introduction to Object-Oriented Design Tools
The article mentions two essential tools for applying Object-Oriented Design:
• UML (Unified Modeling Language): A visual language used to graphically represent software architecture.
• CRC Cards (Class-Responsibility-Collaborator): A simple technique to think about and explore relationships between objects.
My Personal Experience with Object-Oriented Programming :
I do not yet have experience with Object-Oriented Design in my personal projects. However, after reading this article, I now better understand why adopting an object-based approach from the beginning of development is important.
If I were to apply these concepts in a future project, I would start by identifying key objects and their relationships before writing any code. For example, in a website project, I could create classes for buttons, forms, and users, making my code more reusable and easier to maintain.
This reading has inspired me to explore Object-Oriented Programming further and experiment with concepts like encapsulation and inheritance in my future projects.
Suggested Improvements :
• Add Concrete Examples in JavaScript: The example of Smalltalk is interesting, but as the article itself mentions, this language is rarely used today. Illustrating OOP concepts with JavaScript would make the article more accessible.
• Simplify the Section on UML and Metadata: The author’s personal story is interesting, but it contains dense information and technical jargon (metadata, SCL, ModelCompiler). A beginner might struggle with these details and miss the connection to core OOP concepts.
Thanyou very much.
Hi Salomon,
Thank you for your thoughtful and positive feedback on our article “Thinking in Objects: A Foundation for Solid Software Design”! I’m glad you found it helpful and that it resonated with your own experience.
You’re absolutely right that the article is meant to be an introduction to object-oriented design (OOP) concepts. Its main goal is to demystify OOP and encourage beginners to start thinking in terms of objects. While we briefly mentioned CRC cards and UML as tools for visualizing designs, we didn’t go into great detail about them.
That’s where the next article in the series, “Visualizing Your Designs: An Introduction to UML,” comes in. It will provide a deeper dive into UML and how to use it to create visual representations of your software designs. I encourage you to check it out after you’ve had a chance to digest the content of “Thinking in Objects.”
I’m glad you’re interested in learning more about OOP and applying it to your projects. I encourage you to continue exploring and experimenting with the concepts. If you have any further questions or feedback, please don’t hesitate to reach out.
Object-Oriented Programming (OOP) is a powerful way to structure code by thinking in terms of objects—just as we naturally recognize objects in the real world. Instead of scattered code snippets, OOP organizes software into self-contained units with properties (data) and behaviors (methods).
Why OOP Matters
Modularity – Breaks complex problems into manageable pieces.
Reusability – Objects can be reused across different projects.
Maintainability – Changes in one object don’t require rewriting the entire codebase.
Abstraction – Hides complexity, focusing on essential functionality.
OOP in Practice
While languages like Smalltalk are purely object-oriented, others like JavaScript mix OOP with other paradigms. Regardless, understanding OOP principles helps build structured, scalable, and reusable software. Tools like UML diagrams and CRC cards help visualize and plan object roles effectively.
Looking Ahead
Next time you code, think about the objects in your program—what they represent, their properties, and their behaviors. Mastering OOP is key to writing clean and efficient software.
Hi Efatha,
Thank you for your thoughtful comment on our article “Thinking in Objects: Why Object-Oriented Design Matters.” You’ve done a great job summarizing the key benefits of OOP and how it can transform our approach to software development. I’d like to add a few points to your explanation:
The Importance of Thinking in Objects: As you mentioned, OOP encourages us to think about our code in terms of objects. This is a fundamental shift in mindset that can be quite powerful. By thinking about objects, we can better understand the relationships between different parts of our software and how they interact with each other. This can lead to more intuitive and maintainable code.
The Role of Abstraction: You mentioned how OOP allows us to hide complexity through abstraction. This is a crucial aspect of object-oriented design. By abstracting away the details of how objects work, we can focus on their interfaces – the methods and properties that we can use to interact with them. This makes our code easier to understand and use, even for developers who don’t know the inner workings of the objects.
Beyond OOP: While OOP is a powerful paradigm, it’s not the only one. Other approaches, such as functional programming, also have their own strengths and weaknesses. It’s important to be aware of these different approaches and choose the one that best suits your project and your own personal style.
I’m glad you found our article helpful. If you have any further questions or would like to discuss any of these topics in more detail, please don’t hesitate to ask.
I’ve realized that programming doesn’t have to be just a bunch of instructions. We can organize it in a way that mirrors how we naturally think about the world, by using ‘objects.’ Think of an object like a specific ‘thing’ – a car, a person, or a button on a screen. Each of these things has its own set of characteristics (like a car’s color or a person’s name) and actions it can perform (like a car driving or a person talking).
Object-oriented programming (OOP) is all about building programs using these objects. It makes coding feel more natural because we’re working with concepts that are familiar to us.
Here’s why I think OOP is so useful:
It keeps things tidy: Each object is like its own little package, so you don’t have to worry about one part of your code messing up another.
It saves you time: Once you’ve created an object, you can reuse it in different parts of your program, or even in completely different projects.
It’s easier to fix things: If you need to make changes, you can focus on the specific object that needs fixing without worrying about breaking everything else.
It simplifies complex stuff: Objects let you hide the complicated inner workings of something and just focus on what it does. It’s like driving a car – you don’t need to know how the engine works to use it.
To help plan and design these objects, I’ve discovered tools like UML and CRC diagrams. These are like blueprints that help you visualize and organize your objects before you start writing code. It’s like planning a house before you start building it, making the whole process smoother and less chaotic.
Regarding a project I’ve been working on recently, here are some objects involved, their properties and behaviors. The project was to create a landing page with HTML and CSS.
Objects (Elements) and Their Properties/Behaviors:
1. HTML Document:
* Properties:
– font-size: Sets the base font size for the document (62.5% of the browser’s default).
– overflow-x: Prevents horizontal scrolling.
– ::-webkit-scrollbar: Styles the browser’s scrollbar.
*Behaviors:
– Scrollable (vertically).
– Uses custom scrollbar styles.
2. body (Document Body):
* Properties:
– background: Sets the background color to white (var(–white)).
*Behaviors:
– Container for all visible content.
3. .Btn (Button Element):
* Properties:
– display: Inline-block, allowing for width/height adjustments.
– padding: Adds space inside the button.
– border: Defines the button’s border.
– background: Sets the background color to pink (var(–pink)).
– color: Sets the text color to white.
– font-size: Sets the text size.
– border-radius: Creates rounded corners.
– position: Relative, for positioning the pseudo-element.
– overflow: Hidden, to clip the pseudo-element.
– z-index: Manages stacking order.
– margin-top: Adds space above the button.
– max-width: Limits the width of the button.
* Behaviors:
– Clickable.
– Has a hover effect (background color change).
– Has an animated background effect on hover, using a before pseudo element.
4. .header_top (Header Top Section):
* Properties:
– display: flex; : uses flexbox to align items.
– align-items: center;: vertically aligns items.
– justify-content: space-between;: distributes space between items.
* Behaviors:
– Arranges the logo and “Try It Free” button horizontally.
5. Social media icons (.fab):
* Properties:
– margin-left: creates space to the left of each icon.
– border: creates a dotted border.
– padding: adds space inside the border.
– overflow: hidden, to clip any content that goes outside.
– cursor: pointer, changes the cursor when hovered.
* Behaviors:
– When hovered, the icons will translate to the left, and the color and border will change.
Hi Theo,
Thanks for your thoughtful comment and for sharing your experience with object-oriented programming (OOP). You’ve absolutely nailed the core concepts: OOP is indeed about organizing code in a way that mirrors real-world objects, making it more intuitive and maintainable. Your analogy of objects as “little packages” and your points about reusability, maintainability, and abstraction are spot-on!
Regarding your project breakdown, you’ve definitely approached the landing page development with an object-oriented mindset, recognizing the different elements as distinct entities with their own properties and behaviors. While your breakdown is very detailed and focused on the CSS properties and behaviors of the HTML elements, your interpretation of the HTML and CSS elements as objects is interesting.
In a strict OOP context, especially in languages like Java or C++, objects are more about encapsulating data and functionality together. In your example, you’re primarily describing the visual properties and interactive behaviors defined by CSS. While CSS does allow for styling elements and adding interactive effects, it doesn’t quite fulfill the complete encapsulation aspect of a traditional OOP object.
However, your approach demonstrates a key aspect of good software design: recognizing and organizing components into manageable units. With the use of modern CSS frameworks that use the BEM or Atomic design principles, developers are able to componentize their CSS and HTML in a way that is very similar to OOP.
Your breakdown is a good example of how to think in terms of components, and how to define their properties and behaviors. This is a crucial step towards understanding true object-oriented design.
Keep exploring and experimenting! Your understanding of OOP will continue to deepen as you work on more complex projects and explore different programming paradigms.
Reading Michael Kent Burns’ article, Part 2 – Thinking in Objects: Why Object-Oriented Design Matters, gave me a deeper appreciation for how object-oriented programming (OOP) aligns with human cognition. The analogy of a toddler recognizing a cat based on its properties (fur, tail, whiskers) and behaviors (purring, meowing, moving) illustrates how we naturally think in objects. This approach helps us break down complex systems into smaller, more manageable parts, making our code more maintainable, scalable, and reusable.
Strengths of Part 2 – Thinking in Objects: Why Object-Oriented Design Matters
1. Clear and Engaging Analogies
• The analogy of how toddlers recognize objects based on properties and behaviors is an excellent way to introduce object-oriented thinking. It makes the concept intuitive, especially for readers new to OOP.
• This approach aligns well with how developers should think about software design—breaking down complex systems into understandable, reusable parts.
2. Good Justification for Object-Oriented Design
• The article effectively explains why OOP is a natural fit for human cognition and problem-solving.
• It highlights the benefits of structuring software in a way that mirrors real-world entities, making code more maintainable and scalable.
Areas for Improvement
1. More Practical Code Examples
• While the theory is well-explained, the article would benefit from concrete examples of OOP in action.
• A simple code snippet comparing procedural programming vs. OOP (e.g., defining a Car object in Python or Java) would make the discussion more actionable for readers.
2. Stronger Transition Between Sections
• Some transitions feel abrupt, especially when moving from cognitive psychology to Smalltalk’s role in OOP history.
• Smoother progression, perhaps by introducing a section that bridges human thinking and actual software implementation, would improve the flow.
In my recent coding project, where I developed a webpage displaying two Bible passages per day—one in the morning and one in the afternoon—I unknowingly applied some of these OOP principles. Now, with a better understanding of object-oriented design, I can analyze how different components of my project can be structured as objects with defined properties and behaviors.
Objects in My Project
1. The Page Object
Since my project is a content-based web application, the webpage itself can be viewed as an object.
• Properties:
• title : The title of the webpage
• date : The current date for selecting passages
• morningPassage : The Bible passage displayed in the morning
• afternoonPassage : The Bible passage displayed in the afternoon
• theme : User-selected light or dark mode
• Behaviors:
• renderPassages() : Displays the Bible passages dynamically on the page
• changeTheme(newTheme) : Updates the page’s appearance based on user preference
• refreshPassages() : Reloads new passages when the day changes
2. The User Object
Even though my project does not require user authentication, considering the user’s interaction as an object helps structure the experience.
• Properties:
• preferences : Stores user settings (e.g., preferred theme)
• lastVisit : The last time the user accessed the page
• viewHistory : Keeps track of previously viewed passages
• Behaviors:
• savePreferences() : Stores the user’s theme preference in local storage
• loadPreferences() : Applies the stored settings when the user revisits
• trackVisit() : Updates the last visit date for future enhancements
3. The Passage Object
Each Bible passage displayed on the webpage can be treated as an object with specific attributes.
• Properties:
• text : The full passage text
• reference : The book, chapter, and verse reference (e.g., John 3:16)
• timeOfDay : Indicates whether it is a morning or afternoon passage
• Behaviors:
• display() : Shows the passage on the webpage
• fetchNewPassage() : Retrieves a new passage when needed
• highlightVerse() : Emphasizes key phrases for better readability
4. The API Object (If fetching passages dynamically)
If my project evolves to fetch Bible passages from an API, an API object would be useful.
• Properties:
• apiURL : The URL of the Bible passage API
• version : The Bible translation being used (e.g., KJV, NIV)
• Behaviors:
• fetchPassage(timeOfDay) : Retrieves a passage based on the time of day
• parseResponse(response) : Processes the API response to extract the passage
• handleErrors(error) : Manages errors when fetching data
How OOP Would Improve My Project
Thinking about my project in terms of objects, properties, and behaviors reveals areas for improvement. Right now, my code might be too procedural—mixing logic and UI interactions in the same script. If I refactored it using OOP, I could:
*Make the code modular : Each object would handle its own responsibilities, reducing redundancy.
*Improve maintainability : If I need to add features (like selecting different translations), I could extend the Passage object instead of modifying multiple scripts.
*Enhance reusability : The same passage structure could be used for different display formats (e.g., a daily email or a mobile app).
Conclusion
Michael Kent Burns’ discussion on object-oriented thinking has given me a new perspective on structuring my projects. I now see how breaking down a web application into logical objects makes development smoother, more efficient, and scalable.
For my next steps, I plan to:
• Refactor my code to use classes and objects more effectively.
• Separate UI logic from business logic for better organization.
• Implement local storage to save user preferences persistently.
• Explore API integration to dynamically fetch Bible passages.
By applying these OOP principles, my project will be more structured, maintainable, and ready for future improvements.
Hi Samuel,
Thank you for your thoughtful and detailed feedback! We appreciate you taking the time to share your insights and how the article resonated with your own coding project. Your example of structuring your Bible passage webpage using objects like Page, User, Passage, and API is a great illustration of applying OOP concepts. We think you’re absolutely on the right track with your analysis and planned improvements. Keep up the great work!