practical 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 talking about practical object-oriented programming. We've gone through quite a few different topics and we are now going to focus this one just on cohesion. We're going to talk about big object approaches to our design. There are definitely some pros and cons to this. In the next few episodes, we're going to look at the pros and cons of a big object approach, a larger number of small objects approach, and then trying to find some balance between these extremes. From the big object approach, I'll start with the positives. We'll probably throw some negatives in along the way here as well. It's not so much pros and cons as just trade-offs. I see a lot of these things being. When you've got a big object, one of the nice things is you don't have to spend time worrying about what is and what is not a part of that object, or at least you have less of those kinds of situations. You think about it, if you go to the ultimate extreme, you have one object. You have an application object, all the methods exist, all the properties exist, and you're off and running. Now, of course, that does have some challenges because then when you actually do stuff with those properties and those methods, it's not really organized. It's the thing about having it at your desk or at work or home, wherever you're working. If you've got everything out on your desk, then it's all easily accessible, but also can be confusing to figure out what is where. There are some things you can do within that large class that will help you, and it points to some of the things we've already talked about. Another thing is consistency. Things like naming standards. This actually goes to some of the prior variable and method naming or function naming approaches that I've seen in the past, where you have some sort of a code or prefix or something to really help organize the methods and the properties. For example, maybe every property starts with a P underscore for its name. Maybe you essentially group methods by starting the name with what they work on or what they work with. Maybe it could be for database stuff, so maybe dbsave, dbload, dblist, something like that, that you use for those methods. Maybe there are some sort of calculation type stuff, so maybe you just do calc, calc, and then the name to prefix those methods, or put suffix as well. Just something that gives the user a way to look at the name and understand it, understand what it does, but also it is very helpful when you're particularly with large objects because you're going to have more than likely a large number of properties and a large number of methods. Some way that you can sort those or do something that allows you to see as much as possible the related methods. If you don't have a large object, this is something that would probably be something that you'd be hashing your way through to create some classes that would work together so you would group those functions. A single object or when you get to larger objects, you don't do this as much. This is another point for large objects. If you have one, it's easier to stay consistent within itself, I guess. If you have multiple objects, then you want to take whatever that approach is and you want to carry it through to all the objects. For my primary example, if your database related functions in one or methods all start with a DB, then do that across all your classes. That way when they go to the big monolithic, let's say customer class from the big monolithic class, then they'll be able to look for the DB functions and find the ones that do the work that they're concerned about. Now, in a similar fashion, one of the nice things about a large object approach is you rarely run into access related issues. You don't have to worry about something being private and unavailable to one specific class versus another one. They're all there, or for the most part they are. It's sort of like building an application without worrying about security. You don't have to worry about permissions and rights and things like that. You just have access to it. Everybody has access to it. I don't know what you really want to refer to it because there's value and there's an much like security that you have to worry about for the private and protected and public. It's not just like an administrative thing, but however you view that work, that could be essentially limited and maybe even eliminated when you go with the big class approach. Just pile everything in there so everything can have access to it. You also don't worry about, or at least depending on how your application is built, you probably aren't going to worry too much about passing things around and what needs to get passed from one method to another because they're all part of that class so they all have access to it. It's just one big chunk of data and functionality and things like that. You just work within that. You don't really have to leave the comfort of your class very often. That does point to some of the downsides as well. If you for some reason have some sort of a distributed application, then when you pack your stuff up and go, you're packing up a lot. All that data, all those functions, everything are going to be that class. If you do it in a ... If you have some sort of a streamlined way to do persistence and things like that, it may not matter as much because you'll have effectively, you'll have all of those methods at whatever the client is, the starting point. You serialize it essentially just the data, which you would effectively do anyways, send it across the wire and then you reconstitute it on the other end. Now granted, you may be sending more data than you need because maybe doing some rather simple kind of function, but because of this large object approach, there is not a way, we really don't provide a way with the classes at least to send small amounts of data. Instead, we would need to handle that through parameters in our methods, which again becomes one of these things. That's a similar kind of problem that we run into or that we have to be aware of when we go from the big class to the small class approach. When we have a big class, we probably don't want to send the whole class very often. Our methods more likely, if we're calling from another instance or something like that, more often what we're going to do is we're going to have a larger number of parameters because we're going to just parameterize the data we're going to need to work with. Whereas, if we're using smaller classes, we may just send the class across and let it deal with it. Again, there's pros and cons to that. There are limitations and also some abilities to scale based on that. That again is a long-term ultimate goal of our application that we want to consider as we're moving down this path of either larger classes or smaller classes. What is this thing going to be when we're done? How does this approach we take, so if we take the large class approach, how does that look in version two, version three, version four of this application? Is this going to limit us or is it something that's going to work fine not only today but a month from now, a year from now when we're a couple of versions beyond where we are at this point? Now, we get with this large approach, as I said, we have less things to worry about in a sense because it's just all there. That also means that we do have, in a lot of cases, the ability to do stuff a little faster. There is some performance and I guess improvements or positives that we get because we don't have the layers that you end up getting when you've got smaller classes. You have really just everything's there, so you can just directly access a value, directly access the property. You don't have to go through getters, you don't have to go through setters, you don't have to instantiate an object and then go load or anything like that. It's just all there. That does mean that when you're doing calculations and things of that nature, that all of those layers are removed, and particularly if you're doing a large number of iterations, that can make a huge improvement. There's a big difference. If you do it, call it once, it's one thing, but if you call it a million times, that's completely different. With that, with the big object approach, you have one place to go to that you can focus on managing cache and memory and things like that. Is it that object has what it needs by default, by the way it is, it has what it needs to understand what it's, we'll say footprint is. What are the values that it's holding on to? How big is this thing in memory? Again, if you go the ultimate route of just one big application class, then you know how much that space that takes up memory-wise by just, it can just check its instance size and say, okay, how much space am I taking up? Boom, that's how much that I'm taking up on the system. With that, you can do things like limit. It can look at stuff and say, hey, I'm getting too big. I need to maybe remove some of these values or store some of this stuff off or things like that. It can manage its own environment. We see this in applications to some extent. I think a good example to this would be a lot of these major relational database management systems. What they do when the application spins up is it grabs X amount of space. Sometimes it's part of its settings. Sometimes it just grabs as much space as it can, as much memory as it can, and then essentially allocates it. Basically it just runs out into the wild west of the memory of the machine and says, boom, all of this is my area. This is mine. Once that does it, it manages its memory. If you have hard settings, a lot of times that's what happens as well. You say, okay, you can take four gig of space. It takes four gigs of space and then it doesn't take anymore. It holds that chunk and it works with itself to manage memory and things like that. Big classes can do the same thing. Since they don't have to integrate with these other classes, they have much more power within the domain that they have. You think again from a political structure. If you have a king that has his lands and he just says what he says, then he can control everything. If you have something where you've got a council and they've got all of these regional leaders, then the council's got to agree something and then they've got to transfer it to the districts. The districts have got to decide where they're going to follow it and all that kind of stuff. There's a lot of communication that goes on that can be streamlined if you have a single approach. Hopefully that gives you some ideas. It's really been focused, I think, more on the strengths of the single object approach. Then we're going to look at the larger number of smaller objects approach, coupling and what are some of the things there. Then we'll swing back around and see what kind of a mix makes sense. Challenge of the Week. For this one, what is maybe the biggest object that you work with as far as just its not having a lot of properties and a lot of methods and things like that. If you do it all, maybe you have something that's a lot of small, tiny objects. Take a look at that and what it does that maybe it can do only, the only reason it can do it the way it can is because it's that large object approach. Something to think about there until we meet next time. As always though, until we do, 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. One more thing before you go, the Developer Noor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. So you can go back and have yourself a great day.