Functional independence

A concept tied to modularity in software, occurs where a package or class addresses a specific functionality. Having many functionally independent modules makes a software system resilient to change: because functionally independent modules rely on fewer other modules, there is less chance of changes to these modules spreading to those which are functionally independent. Functional independence means that changes in one component are less likely to affect the software as a whole. The modules conceals content from unauthorised entities, showing what's necessary only to this functionality. This constraint requires the help of fewer other modules to exert this control. In the software industry, functional independence can be measured using two criteria: cohesion (the degree to which a module performs only one function) and coupling (how other modules are required to perform its function). Cohesion can be understood as the measure of a module's relative functional force. It is the degree to which interrelated tasks are executed by a single module. In object-oriented projects, cohesion can also be seen as how much a class encapsulates attributes and operations strongly related to each other. Coupling is a measure of relative interdependence among modules. In object-orientation, coupling is the degree to which classes are linked to each other. Cohesion and coupling metrics evaluate how components rely on each other. With a very dependent set of functional requirements, the solution tends to be have a degree of subordination to the inner workings of other components. Object-oriented development makes it easier to create reusable components. That's why this paradigm makes use of abstractions such as classes, objects, interfaces, attributes and methods. Encapsulation, inheritance and polymorphism also help reusability, extensability and maintenability. That's why the most important task in object-oriented projects is the identification of classes and the responsibility assignment of the same. Software patterns have been created in order to help the project professional in this decision process. A pattern is compound binary made of a problem and a matching solution, with a name and applicability in new contexts and guidelines about to use best to use it. The use of patterns allows for the reuse of existing solutions to cut back on time and effort that would be used to think up an entirely new solution. Its premise rests on past successful experiences and tried and proven architectures. The universal goal of functional independence is to maximise cohesion while minimising coupling.