In this video, we'll take a closer look at what we mean when we say modularity. When we talk about modularity, we're primarily talking about these four things. Coupling, cohesion are measures of how well modules work together and how well each individual module meets a certain single well-defined task and they tend to go together, so we'll talk about them separately. Information hiding describes our ability to abstract away information and knowledge in a way that allows us to complete complex work in parallel without having to know all the implementation details concerning how the task will be completed eventually. And then, data encapsulation refers to the idea that we can contain constructs and concepts within a module allowing us to much more easily understand and manipulate the concept when we're looking at it in relative isolation. The reality is that software development is the most complex thing we as humans have ever done. Building a bridge is hard, but you can see it. You can roll a truck across it, watch and see if the bridge collapses or sways or cracks while you're doing that. There are physical world properties that it must adhere to that we can leverage to ensure we've done our job. Software isn't like that. You may never know there's a huge crack down the main line of your program just waiting for you to enter the wrong value and collapse in front of you. Attempting to hold the entire concept of a large scale program in your mind all at once is a fool's errand. We have no choice but to break the problem down into smaller parts which we might then be able to comprehend. To do that properly, we're going to focus on three concepts, three listed here. Decomposability. Essentially it's the ancient, possibly Roman, concept of divide and conquer. When the problem is too large and complex to get a proper handle on it, breaking it down into smaller parts until you can solve the smaller part is the way to go. Then you just solve all the smaller parts. But then we have to put all those smaller parts back together and that's where composability comes into play. This is often not as simple as one would like. If you don't believe me, ask NASA. The Mars Climate Orbiter disintegrated during its mission because of a mistake in units with one module using pound-seconds and the other using Newton-seconds when calculating its thruster's total impulse values. It's the little things that make this so difficult. We're talking about taking a complex thing to begin with and then making it even more complex by adding who knows how many intersection points between different developers or even developer teams. The likelihood of a miscommunication just makes it all the more difficult. So we try to focus on ease of understanding by breaking down the components we hope to provide an ease of understanding, which will then hopefully lead to an ease of communication. When it comes to information hiding, what we want is the ability to use something by understanding what it does but not necessarily how. This tends to work well until the understanding of what it does is strained. Take rand(). What does the function rand() do? Well, you might answer that it provides you with a random number but that's not quite right. For most purposes, it generates a random enough value for most uses, but in reality, rand() is a pseudo-random number generator. It's based off of a seeded value and isn't exactly random. So when you need true randomness, it doesn't quite fit the bill. But, it does work in many typical situations where true randomness isn't quite necessary. Here's another example. Have you ever used the internal sort function in your language? Do you know how it sorts the values? Is it quicksort, or merge sort, or insertion sort, or bubble sort? Well, I hope it's not bubble sort but really you don't know. And for the most part, you don't really care. In most situations, all you want is that when you provide the array it gets sorted. As long as it gets sorted and there isn't a performance issue, the information hiding is perfectly acceptable. You know how to use it and what it does behind the scenes doesn't concern you. Because of data encapsulation, protecting the data from unauthorized access and maintaining integrity is a key point. The developer of a module has the best idea of how and when the attributes should be modified, and then we try to allow them to maintain as much control as is possible. Nobody else is allowed to mess with that data. If it gets corrupted, it must have been done by the module, that's the intent. And by robust here, I mean that chances are that new additions aren't going to break the current design. So when we talk about modularity, we're really talking about breaking down and reassembling all these components. So when it comes to coupling, cohesion, information hiding, and data encapsulation, they are just qualities, different perspectives on what modularity really means.
