A lot of the work of a developer and determining how things come together, comes down to the developers themselves.
In today's episode we're talking about a misconception that many developers carry about object oriented programming. We'll keep the episode short today but in today's episode we'll talk about object orientated programming as a message.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Many of us taught ourselves programming, and many of us have some kind of formal background as well. Really for every programmer, you probably have a mix of both. The resources available to you are somewhat formalized, but a lot of the work comes down to you learning how the stuff fits together. And there are a lot of opinions about how these things should fit together. In today's episode though, I want to focus on what I believe to be a misconception in object-oriented programming. Something that very often, especially self-taught developers, but I've certainly encountered this with more formally taught developers as well, a misconception that can hold you back from writing much more fluid and intuitive code. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And this misconception about object-oriented programming is a subtle one. It's a nuance because it's not so much an incorrect picture of how these pieces of the puzzle fit together. Instead, it's an incomplete picture. And we'll keep this very short today because this concept is rich and you'll find it happening over and over in your code. This is something that you can apply to a lot of different kind of methodologies, a lot of different paradigms of programming, but it especially applies to object-oriented because people come to object-oriented thinking that object-oriented programming is about having all of these various objects that can perform some action either on their own or on other objects. And I want to help you shift that mindset in today's episode. It's a very simple shift and the idea is this. Objects in object-oriented programming are anything that can receive a message. Now the semantics here can be important depending on your opinion, certainly in different kinds of programming languages. The semantics matter more than other languages, even if both languages are object-oriented. But I want you to think about this less in terms of the technicalities, the differences between a message and, you know, invoking a method, and instead think about it conceptually. Anything that can receive a message. So this doesn't have to be, for example, a representation of a physical object. This is perhaps one of the most common blatant and obvious examples of this misconception. Seeing all of the objects in a given program be able to relate to some physical objects in the physical world. Another version of this misconception is seeing all of the objects in a given program being nouns, only being nouns. Instead of thinking of your objects as literal objects, or instead of thinking of them as kind of grammatical objects, things that can perform some action, consider them to be able to take some kind of message. You can think about this as taking some kind of input or taking some kind of direction. An example you might see in the real world of this is a process like a user signup class. And this user signup class may take the message run or execute. Or it might take a message that we couldn't predict on this show because of something specific in your application. If we think about classes or objects in the old way where they have to be nouns, then very often, a symptom of this problem is that we see some kind of controller in the MVC mindset or some kind of procedural response that ends up handling what we could use a class to handle. And these procedural responses, these controllers tend to be difficult to manage. They tend to be difficult to understand. And they tend to hold a lot of different behavior in a single controller. A lot of totally separated behavior in a single controller ends up very often showing up. As a rule of thumb, a good object-oriented programming environment is one where classes do not have to be heavy weight. They don't have to be large to substantiate their own existence. Instead, classes can be used to encapsulate a way of thinking, to provide language to something, and ultimately to send and receive messages. Thank you so much for listening to today's episode of Developer TV. If you enjoyed this episode, I encourage you to subscribe and whatever podcasting app you use. And today's episode also wouldn't be possible. That's spec.fm and our wonderful producer, Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.