RailsConf 2015
Nothing is Something
Nothing is Something
by Sandi MetzIn the talk titled 'Nothing is Something,' Sandi Metz explores the hidden assumptions within code and emphasizes the importance of understanding these complexities for better coding practices. Metz conveys a core message drawn from her extensive programming experience, notably influenced by her background in Smalltalk, and focuses on how to make code simpler, clearer, and easier to maintain by being explicit about the underlying concepts. She outlines her presentation in four parts:
- Understanding Objects: Metz reflects on her distinctive perspective of objects, shaped by her experience with Smalltalk, particularly regarding the Ruby programming language's syntax and function.
- Communication with Objects: She discusses the Ruby send method, highlighting how it enables method invocation and suggests that many programmers misunderstand interactions with objects due to a procedural mindset.
- Avoiding Conditions: Metz addresses the common practice of checking for nil values in code, advocating for a mindset shift towards message-sending instead of relying heavily on conditional logic. She introduces the concept of the null object pattern as a way to handle situations where a method might return nil, thus simplifying code and reducing potential errors.
- Good Object-Oriented Design Principles: She draws connections between the null object pattern and broader design principles, urging developers to focus on isolating behaviors and defining clear roles for objects to enhance code clarity and maintainability.
Throughout her presentation, Metz utilizes the narrative of 'The House that Jack Built' to illustrate the power of abstraction and thoughtful design without resorting to complex conditional logic. She concludes by reinforcing the idea that multiple valid implementations exist for coding practices, and effective design comes from intentional decision-making. The key takeaway is that programming involves recognizing everything as having significance—nothing is truly 'nothing' in code, as each element serves a purpose. Metz also invites engagement and sharing of her upcoming book, extending the conversation beyond the talk itself.
00:00:12.280
Thank you for coming. I'm Sandi Metz. I was a programmer for 35 years, and I'm a woman of a certain age. A couple of years ago, I wrote a book. When it came out, it was like a bomb went off in my life. I had to quit my day job because I was so busy doing other things. As a result of quitting my day job, I needed a way to make a living, and people kept asking me to teach. So, I finally broke down and agreed to teach short object-oriented design classes.
00:00:35.800
Then I had to create a curriculum, which was quite a challenge. I sat down and figured out what I thought were the most important lessons I could teach in three really intense days. When creating that curriculum, I mistakenly thought that the lessons were all unrelated. They were all good topics, yet I believed they didn't connect. However, after teaching the course for the last year and a half, I finally realized that I wasn't teaching a bunch of different ideas but was really conveying one simple idea.
00:01:03.120
So, today's talk is everything I've learned in the last year and a half, compressed into 30 minutes.
00:01:07.159
This presentation is going to involve a lot of slides. Based on my calculations, I'll be changing slides about every four and a half seconds once we get going. If you want to change seats, now is not too late to move over to the sides. You've been warned!
00:01:20.119
This talk is divided into four parts, and I'm going to build up from the bottom. The first part of the talk, after my book was published, made it really clear to me that I had a different understanding of objects compared to many people in our community. I was curious about why that was.
00:01:32.840
Upon reflection, I realized that my perspective was shaped by my experience with Smalltalk. I've been writing Ruby since 2005, but I haven't written Ruby as long as I worked with Smalltalk. I say I was 'infected' by Smalltalk; it’s a funny term, but really, I see myself as being inoculated by it.
00:01:44.760
Today, I’m going to show you a brief example related to how I think about objects in Ruby, stemming from my experience with Smalltalk. Now, let’s discuss the Ruby language, specifically the send method, which allows us to invoke methods by sending symbols. You may or may not be familiar with this concept.
00:02:04.000
In Ruby, if I want to invoke a method named 'x', I could do this using the send method. And surprisingly, Ruby also has this syntax: when I say, ‘1 + 1’, it may look like math, but in reality, I am sending a message to an object. And here, that object knows how to process that message.
00:02:29.120
Now, let’s explore what I mean by 'this'. In Ruby, this is used for method calling and holding references. I might surprise you by stating that true and false are, in fact, objects. When we send messages to them in Ruby, they respond according to their classes.
00:02:51.280
I found this unsurprising because I came from Smalltalk, where such concepts were common. However, I was shocked to discover Ruby's unique syntax designed for handling boolean values. Ruby has specific keywords for conditionals, a concept that feels foreign to someone with experience primarily in other OO languages.
00:03:36.360
Typically, in an object-oriented language, we communicate with objects without specifying type checks. Yet, in Ruby, the presence of certain keywords encourages a procedural mindset, which might hinder our transition into object-oriented programming.
00:04:23.520
To highlight this issue, let's imagine a scenario where we would have to modify Ruby's conditional syntax to align more closely with a pure message-sending method. If we were to transform the default handling of conditions to follow more of a message-sending paradigm, it would alleviate some of the difficulties in thinking procedurally.
00:04:44.920
Now, to illustrate this further, let's consider how we often need to handle nil objects. Suppose we have a class that has a method to find an object by ID. If the ID isn't recognized, it returns nil. This can lead to dangerous errors if not handled properly. In many cases, we simply place a condition around potential nil responses, leading to cluttered, verbose code.
00:05:31.559
I dislike using conditions to check for nil values or status because it often creates branching logic that complicates the code. Instead, we should focus first on message sending. It’s important that the code remains clean and focused on sending messages rather than constantly checking types or conditions.
00:06:09.600
The presence of conditions in your code can signify a deeper underlying problem—conditions often proliferate and lead to various complications in the code structure, which is why I advocate for a mindset shift toward messages.
00:06:55.679
So, how do we eliminate the need for conditions? One potential solution is to embrace a more object-oriented approach. For instance, by handling specifics of what a condition checks through polymorphic behavior, we can minimize the need for extensive condition checks.
00:07:26.640
This paradigm shift leads us to the concept of the null object pattern. In essence, a null object serves as a placeholder that fulfills the expected behavior of an interface without the need for special case handling.
00:08:21.760
By implementing a null object, you can significantly reduce your reliance on conditions while simplifying and clarifying your code. Instead of checking for nil, you can rely on this active nothing to handle cases where you would have otherwise encountered a null, thus removing clutter.
00:08:56.640
The null object pattern can prevent errors and improve the code's readability, easing maintenance and further development. However, although this sounds simple, it’s critical to consider that the design should favor clarity and the understanding of roles assigned to different objects.
00:09:41.640
In applying the null object pattern, I've realized that clean code often comes down to isolating behaviors and defining roles clearly. It’s necessary to evaluate how your objects interact, tying behaviors together without relying on cumbersome conditions.
00:10:34.760
This exploration of the null object is just one instance of a broader concept—a guide to thoughtful design in an object-oriented paradigm. I want to delve into the larger abstraction at play here to empower you to design better systems.
00:11:19.120
If we shift our focus to a familiar tale—'The House that Jack Built'—we can see how to craft code that embodies this abstraction in a distinct manner that doesn't sacrifice our design principles.
00:12:11.000
By approaching the challenge of creating a randomized or echoed version of this tale without using conditionals, we can better appreciate how order and abstraction intertwine with object-oriented programming.
00:12:56.639
This all circles back to essential principles of good object-oriented design: the careful isolation of responsibilities and leveraging dependency injection wisely to enhance flexibility and adaptability. I’d like to stress the importance of distinguishing between specialization and sharing behavior; the two should not be conflated.
00:13:49.760
To close, I want you to leave with a key takeaway: there are often multiple valid implementations of a method or structure. Good design stems from recognizing these options and making deliberate choices about how to implement and organize your code effectively.
00:14:46.160
So, as you move forward in your journey, keeping the principle of abstraction in mind will serve you well. Pay attention to how we can replace complex conditional logic with the behavior of other objects and enable seamless integration, ensuring a robust and clean implementation of your application's functionalities.
00:15:35.720
Thank you very much for your time today. I'm Sandi Metz, and I truly appreciate your attention. Remember, nothing is ever truly 'nothing' in programming; everything is something that serves a purpose.
00:16:48.080
Thank you. I look forward to hearing your thoughts on this, and I'm excited to engage with you further.
00:17:05.880
I also want to introduce my new book—I invite you to sign up for updates on its release!
00:17:14.640
If you're interested in my teaching schedule, please check my website for those details as well.
00:17:28.240
Thank you all again, and please feel free to approach me afterward; I'd love to chat!
