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 developers. 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 Cottrell and you're listening to Developer T. My goal on 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 a 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. And 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 object-oriented programming is a lot of different kinds of programming. And I think that's a really important thing to consider. And I think that's a 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 be used to perform some action. And I think that's a very important thing to consider when you're bringing together theseension and 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 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 object in the physical world. Another version of this misconception. 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. 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. Uh. 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 heavyweight. They don't have to be large to substantiate their own existence. At the same time, they may have to have a plinth of evolution behind them, bringing evolutionij 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 Tea. If you enjoyed this episode, I encourage you to subscribe in whatever podcasting app you use. Today's episode also wouldn't be possible without Spec.fm and our wonderful producer, Sarah Jackson. My name is Jonathan Cottrell, and until next time, enjoy your tea.