Polymorphism and Communicating Clarity in Object-Oriented Programming

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're looking at object-oriented programming and some of the core concepts and how to make the most of them, how to do so in a practical way. In this episode, we're going to continue our initial talks about polymorphism and communicating and clarity. In particular, it's how polymorphic should you be in using a command in particular. For this episode, I'm going to stick to a simple example that I can see easily extend to something out of control. I think that will actually work very well for us. That's the idea of a print. Just a print method for a class. There are a lot of different things that can contextually be added into that when you're thinking about it. Print could be print to a printer, print a hard copy, print to screen. It could be a console print to screen or a graphical print to screen. If you think of a graphical object like maybe a button or something like that or a slider, if you do print, you may be thinking print to screen. Or it could be a hard copy. For this portion, what we're going to talk about is just for our example is thinking about a print that displays to console. Now, generally, that would make sense. There's some sort of... It's not always print. Sometimes it's called to string or display or something along those lines. But with most of our classes, there's some way to convert an object. I mean, a class itself, but also an object instance to some output kind of string. In some cases, the default, particularly if you think... I think Java still does it. A lot of other... C Sharp, I think, does it. PHP maybe does it. Where essentially, if you do a print and it doesn't have some sort of an override, basically, if you go back to the core, the base class, usually it's object, we go back to that. It's print just prints out the pointer, basically, and pointer address to that class. If you create a class called car in Java and then you create an instance and you print it, you're going to get something along the lines of I think it's like class car and then some hash or hexadecimal or something like that. Basically, it's just a pointer address. Not terribly useful to a user, even in debugging. Normally, what you're going to do is you're going to take that print and you're going to convert that over to maybe... For example, I think a lot of ways I do it, and I've seen a lot of people do the same, is that I'm going to print out the main attributes of that object. For a car, it may be make and model. If you think of an address object, it would be city, state, zip, street address, maybe address line one, address line two, city, state, zip, country, maybe. Now, an address would be a good example of that as well, is about the polymorphic side of it. Now, we may have... Let's say we have an address that's a... We have an address core, like a base class, that is a city, a state, or actually let's just say it's a city and an address. It's a street address. Then we have, let's say for example, US address, which has a zip code, and then you have an estate, but you have Canadian address, which is a zip code and a province. You can save those things as the same, but let's say for our purposes we have those two different classes. Now, down at the core level, we could say print, and it's going to print a street address in a city. And then when we move up to the US or the Canadian one, then maybe that print will then take the print from the root, from the base class, and then extend it and then follow up by printing the zip code and the state or province, depending on which class you're at. Now, that would be a clear, a useful way to do print, because as you get... As you go through that hierarchy, it's consistent. There's certain things you're always going to see. You're always going to see the street address in the city. And then somewhere down the line, there may be something that also displays country in some way. And maybe for the US one and the Canadian one, maybe country's hard-coded. And then in some other subclass, country's just the three-letter country code and is based on whatever's stored for that object, for that instance, somewhere back in the database. So, our polymorphism is a natural outgrowth in this case. The bad way to do it would be to do print and for the, let's say, for the root or the core object, you do address and then city. And then you come back in the US one and let's say you start with, maybe you start with country, say US, and then you do city, state, zip, and then you do the address line. And then for Canadian, maybe you do province, zip code, then street, then city, and then country or something like that, or maybe you don't include country. So now you've got different formats. What's worse is you could easily make one does essentially console output, maybe another one does it in an XML format, another one does it in a JSON format, another one does it in a CSV. I mean, there's a lot of different ways you can do that stuff. And for clarity, and this would be a good example, is let's say I, again, I'm going to build off of my core address. So my core address, I just had a print and it just did a street and a city. So now for US, I can do that and I'll have print and I'll extend that and add state and zip. But now let's say that I wanted to do a CSV version of it now, because I'm doing city, state, zip, that I need to do something a little special to do a CSV. So instead of overriding print or even trying to override print, because some cases allow it where you just give it a different parameter, it's just called print to CSV or print as CSV. Don't be afraid to get descriptive in your names so that your polymorphism doesn't really bite you, because the worst thing to do is to deal with something that is a polymorphic function and find out that it's actually very different from class to class, which would mean obviously also different from instance to instance. I mean, that is, if you haven't run into it, that's probably one of the biggest complaints developers have dealing with object-oriented systems or APIs or anything like that when there's not a consistency, particularly the names. And that's the flip side of this, is because we have this ability to polymorphize our methods, then the expectation would be that I get roughly the same thing back, regardless of what class I call it on. So for example, this goes back to the Canada and the US address types. I should still have, when I output Canada and US, the first bits, the first pieces of that output should look the same as they do for a base address. So I can still work within that. And we'll get a little more into this. In the extending idea of inheritance, that's exactly what we want to do with our polymorphism as well. It should have some sort of a core language or understanding to what it does. And then within classes, maybe we tweak stuff a little bit, but mostly in the idea of tweaking it via extension, as opposed to changing what's there. So for example, if I wanted to take that same address and print it in XML format, I would not... Actually, what I probably want to do is go back to the core class and do a print as XML and then extend it out in these other ones. But what I would not want to do is do a print at the lower levels and then just sort of override it from there and say, oh, okay, now I'm going to go do a print as XML. I don't want to change it fundamentally. And even in some of these things, order may matter, for example, in a print. If I start out by printing street address and state, or I'm sorry, city, then I should have that as part of the subclasses. Now I guess you could prefix it. You could pre-pinned or append to it. You could do both. It's going to be a little more complicated, but I think the easiest way to think about it is you should, when you are using polymorphic behavior in an extended thing, a situation like this, you should be calling up the chain. And now this can be... It can change somewhat when you go from a type of class to another type of class. So if I do a print for a customer, it's going to be different from a print for an address. Or let's say print phone number versus print address. But if print on an address is out to console in a formatted string approach, then my print for phone number should be the same. It should not go from XML to CSV or to JSON or just something else. It should be consistent. And if you have a specified format, it wouldn't hurt in your definition. I guess it would be standard language for that, your standard syntax across your system. Use the as X or something along those lines. So I'd say print as XML everywhere, whether it was an address, a phone number, anything else. So be consistent. And this does go back to design. We have to think about this stuff a little bit. When we get into actual object oriented programming, we want to think through what we're doing. And we do have some help if we're sitting on top of a framework or including libraries, but those also mean we should do what we can to be consistent with those. And when you look at popular languages like C sharp or Ruby or Java or any of those, there are programming standards that are generally accepted. Those are put out by the quote, whoever it is that owns that language. Otherwise, there may be some sort of user groups or something like that out there that essentially help set the standards. That doesn't mean your organization may not be different, but it should be taken into account. The universal standards and then of course, organizationally, take a look there because there may be some standards that your organization does that is not quite universally known, but those are the ones that are going to be obviously more important to you within your organization. That's all I wanted to do. I want to keep this one without going too far field. Keep this one sort of short. Just in thinking about polymorphism, think more about the ideas of being very constrained in what the function is, what the output is. And then also as you grow, do it through extending and building on top of what already exists as opposed to rewriting what exists. Challenge of the week. Take a look back through your stuff. Should you maybe split some of these things up? Maybe you've got a print all over the place and you should have two or three different types of print. Maybe you should have a print, print screen, print to XML, print to file, print to email. I don't know, something along those lines. So sometimes I think about just as you're going through your designs and your code reviews and refactoring all that kind of good stuff. That'll do it for now. So as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noor podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoor.com. Just a step forward a day is still progress. So let's keep moving forward together. Hi, this is Rob from Building Better Developers, the Developer Noor podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers, and we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon. Now back to the show.