Cohesion vs. Coupling 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're consigning our season where we're looking at practical object-oriented programming and approaches. This episode, we're continuing looking at cohesion, coupling big classes versus small classes. In this episode, we're going to look at the small classes approach. This is smaller things working together to build bigger systems. Previous episode, we looked at more monolithic kinds of approaches and really ended up sticking more to the pros, even though we looked a little bit about the pros and the cons. We're really going to do the same thing here because there's not necessarily a right answer. It's more like it's different thought processes or approaches to the problem that you're trying to solve and the solution that you end up designing. Diving into small objects, one of the biggest pros is that you allow it to have a just-in-time approach to solving a problem. When you're building something out from an agile approach, where you don't really know what all you need to do when you start, this is actually a very beneficial approach because you can just build a little object here, build a little object there, build the integrations, and then you move forward. That allows you to really stub stuff out pretty quickly. You can have these objects, these classes that you know you're going to need to some extent, but you don't have to flesh it out. You can stub it out and deal with it later. You don't necessarily have to build all that functionality. You could do that with a large class as well, but with a large class, that means you're constantly going to have to go back and recompile everything, basically, versus maybe being able to do more of a little compile this here, compile that there. Particularly as you get into larger systems, there's a benefit to having something that you don't have to actually rebuild or recompile. You just build it. It's there. It's fairly static. You know that at least it didn't change, even inadvertently, because it was built in the past, tested in the past, and so that hasn't changed. Your integrations to it in that way, but the thing that you have completed, I guess, for lack of a better term, you consider it completed and put it on the shelf and done. You don't have to worry about it anymore. As you're building out, that's sort of a benefit as well, because when you're building new things on, you know when you have bugs and issues that arise, you know where the changes are. Now, it may go back to your new features highlighting and a bug that you didn't catch in the past in your prior code, but more likely, you know, if you have new bugs, if it worked and now it doesn't, then look at what's changed since it worked to help you track down how things broke. Now, another thing is that you get, almost by definition, you get flexibility. Think about it, if you've got a toy that has almost zero moving or detachable parts, then it's pretty monolithic in what it can do. It basically is that toy. So if you think of a car, truck, or vehicle of some sort that has its wheels and no real moving parts, then you can take that and you can, as a child, you can sort of vroom vroom your way around the room and that's it. However, if you've got something that has, you know, those smaller objects approach, those interchangeable things, then there's other stuff you can do with it. You may be able to buy add-ons or maybe you can, you know, disassemble it to some way and reassemble it in certain ways. The opposite approach to having a, like a child's toy that's a vehicle of some sort would be, back to the example I used before, of a bunch of Lego bricks. Because then you can build a car, you can build a plane, you can build a building, you can build whatever you want because you have these smaller objects that you can work with. Now, very similar to that, it takes more work usually to fit those pieces together, which is one of the concerns that we have when we go to this, the coupling, the sort of the helper approach. We have to be much more cognizant, I guess, more intentional about what data goes where. Where does data belong? And then how do we pass it around? Because we have to make sure that the classes that need the data can have access to it, whether it's direct because it's, you know, property within it or whether it's indirectly something that we pass it by sending it another class. That becomes an ongoing concern because we end up in this, we're regularly going to have at least this conversation, I guess, within ourselves or amongst the development team of where does this belong? Going back to a prior example I mentioned where you've got data and you've got these database related functions, you know, save, load, stuff like that. What do you do in that situation when you're dealing with smaller classes? Do you, with each class, do you have that, you know, save, load, let's say save, load, create? Or do you have some sort of a helper that does the save, load, and create and then you pass the class to it and it pulls the properties, values it needs to and does that save, load, and create? And where does that belong? And you also run into, which you're going to run into this with larger objects as well, particularly with smaller objects because there's a lot more communication that goes on. You think about it, if it's one person communication is, there is none. It's just that person knows where they need to go. No, if you've got a hundred people, then in order for them to do something there has to be communication. Everybody has to be told what's going on. Same thing with objects. If you've got a lot of these small objects, there's a lot of communication that goes on amongst them. And so when you do so, you need to have a, which can sometimes be challenging, you need to have a consistent approach to what to expect as far as where data should live and how it's going to be worked on. And this becomes more the challenge that exists really in the coupling approach that doesn't really show up in cohesion is the idea of what, where do things live when it is shared, essentially a shared functionality between classes? A good example that we'll run into a lot is in the idea of collection classes. If I have, let's say, let's say a customer, so I've got a customer class, but then I also have a, let's say there's a location that I have that's basically it's just a collection of customers. So my customers all belong to a certain location. When I perform a function, do I, does that function live up at the collection level or is it down at the individual item level? Now collections and items are a little bit special because it's not uncommon for you to have something that exists at the collection level that really just does a pass through to each of the individual items within the collection. So if I wanted to contact my customers in this example, I would just, I could just tell the location object, contact customer, send message to customers. And then although it has a collection of customers, what it does probably is just spin through the collection of customers and does send message to each of those individually. Now you have two different objects that have things that they work on. Then you run into this situation or they work on the same chunk of data. Then you get into this, not uncommonly at least to say, well, who owns that data? So if you have object A and object B and they both work on this chunk of data, where does that data live or is it its own? Does that imply that we have class C that A and B work with? And sometimes that's what we do. Sometimes that's the easiest way to do it. But there are things like, for example, global type functions and methods that could live down at the class level or maybe you have a global class or maybe you have like a controller or something like that that is sort of overall or an application or something that holds on to those. Maybe you have the idea of not quite mastered detail, but and this gets into when we talk about blended approaches, I guess. Maybe you've got these sort of these like larger classes that store a lot of this stuff and then these smaller classes that are doing more individualized calculations, things of that nature. And it's hard to come up with a good example without going into an actual problem, actually trying to solve something. But we do run into this where you're going to have data even, but more often you're going to have these functions, these methods that really what they do is they work on two different types of objects. You figure out where does that live? And sometimes it does end up being some sort of collection, but sometimes it ends up being two different things. For example, to some extent, like on an invoice, you have two addresses usually. You have the billing address and you have the shipping address. And so things that are address related, you have to run into, you know, do does each address have its own method for that? You know, like if you wanted to, if you wanted to, I don't know, move an address or something like that, and this becomes really, that's probably not a good example because those are separate pieces and they don't work together as much. So unfortunately I don't have anything that's, that's like a really good, obvious and simple example. So I think I'm just going to leave it at the idea that there are going to be cases where I've got a method and it works on my class that I'm working with, but there's also this other class that I really need. Now I can pass the information in and I can get that and that's fine, but it's hard to tell because of the, I guess the equality of sizers or the equal need for the two different classes within the calculations I'm doing, which one makes sense to be the sort of the owner or the driver of that. Sometimes you have situations where it's obvious because you're always going to initiate a method from a certain class. And then there's others where that isn't as clear, where multiple classes could initiate it. If you think of calling a meeting in a company, the managers probably are more likely to call a meeting, but maybe you have a situation where any employee could call a meeting. So if you've got a manager class and an employee class, you may wonder where do those things, where does that live? Now if you've got a good hierarchy, it probably is going to show up somewhere further up the hierarchy that does solve a lot of these problems that a coupling approach can take. Is that you do the, because you can do the coupling through these smaller classes or in a sense you can do the coupling by hierarchy. Is that you can have these shared properties and methods that exist higher up in the hierarchy. However then that does start leading you down the road of having just bigger classes because you're even in those child classes, although it may not have a whole lot of its own, you're carrying along that entire hierarchy of stuff. So it's really cheating your way I guess into more of what would really be a more of a single monolithic type approach. So when you do this, you do have a lot of flexibility because you can take the little bit of functionality, the little bit of data you want to work with and you can break that out and then you can pass it around as needed. But with that, you need to make sure that you're really thinking through what data is needed and if I'm going to be passing that around, how do I populate that data, how do I get that data back out as needed and how do I restrict access to make sure that I protect myself as a class so that I can do my units of work and not have to worry about other things corrupting it I guess. Having other things go in and put a class into a state that is maybe invalid, unexpected at least and maybe actually is directly invalid. So that's just getting the touch of the tip of the iceberg I think on the coupling approach, but I want to get us started down that road and we are definitely not done with it. Challenge of the Week, look at the current application you're working on and does it feel more like a cohesion or a coupling approach? I think we've talked about this enough now. You've gotten some ideas and then in doing so, does it seem like or have you experienced it as being the right approach or is it maybe the case that you should have gone a different direction or whoever designed it should have gone a different direction in their approach? Something to canoodle on until the next time we meet, but until then as always 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 Nord 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 developernord.com. Just a step forward today is still progress, so let's keep moving forward together. One more thing before you go, Developer Nord 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 developernord.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. Now you can go back and have yourself a great day.