y

y y

Abstraction: One point of confusion regarding abstraction is its use as both process and an entity. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. Abstraction, as an entity, denotes a model, a view, or some other focused representation for an actual item. Information Hiding: Its interface or definition was chosen to reveal as little as possible about its inner workings." o Why confusing: Abstraction can be used as a technique for idenfying which information should be hidden. Confusion can occur when people fail to distinguish between the hiding information, and a technique(e.g., abstraction) that is used to help identify which information is to be hidden. Encapsulation: It refers to building a capsule, in the case a conceptual barrier, around some collection of things. o As a process: Encapsulation means the act of enclosing one or more items within a container. o As an entity: Encapsulation refers to a package or an enclosure that holds(contains, encloses) one or more items. o If encapsulation was "the same thing as information hiding," then one might make the argument that "everything that was encapsulated was also hidden." This is not obviously not true. Abstraction means concentrating on what an object is and does, before making any decisions about how the object will be implemented. Thus, abstractly, we define a deck of cards and the operations we want to provide. (Clearly, if our abstraction is to be useful, it had better capture the attributes and operations of a real-world deck.) Once we have decided on the attributes and operations, we can actually implement them. Encapsulation, which is also referred to information hiding, means separating and hiding the implementation details of the chosen abstract attributes and behavior from outside users of the object. The external side of an object should provide only the necessary interface to users of the object for activating internal procedures. Imposing a strict insideoutside discipline when creating objects is really another way of saying that the object successfully encapsulates all implementation details. In our deck-of-cards example, encapsulation means that the user need never know how we have internally modeled the deck or how an operation, such as shuffling, is performed; the user need only know how to activate the given operations. Information hiding refers to the principle that how a class in internally constructed is not relevant to any programmer who wishes to use the class. That is, the implementation can and should be hidden from all class users precisely to ensure that the class is not altered or compromised in any way. All that a programmer need to know to use the class correctly should be provided by the interface. Cohesion is about making sure each component does one thing and does it well. The lines get blurry in a language like Ruby, where one "component" could be a library that reopens a class like Object and in effect extends every object in the system. The specifics doesn't really matter. What matters is whether the code is self contained. It's generally easier to reduce coupling in a highly cohesive system. It is easier, because a highly cohesive system will group the related functionality together, so that the need to communicate across component boundaries (whether those

y y

"components" are classes, separate processes, or methods injected into reopened classes by a library) is reduced. The key point is that related code often share state. Sharing state across component boundaries increases dependencies. Increased dependencies increase coupling. Cohesion and coupling are thus not at odds - high cohesion and low coupling are both good, and achieving one tends to make achieving the other easier, not harder. When some people think that high coupling is sometimes excusable, it is often because they confuse cohesion with consistency and ease of use.

Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.
y y

Someone had vague reference to decomposability here. Clarification? How about: 'Cohesion is inversely proportional to the number of responsibilities a module/component has.'

Coupling between modules/components is their degree of mutual interdependence; lower coupling is better.
y y y y

size: number of connections between routines intimacy: the directness of the connection between routines visibility: the prominence of the connection between routines flexibility: the ease of changing the connections between routines

A first-order principle of software architecture is to increase cohesion and reduce coupling. Cohesion (interdependency within module) strength/level names : (from worse to better, high cohesion is good)
y y

y y

y y y

Coincidental Cohesion : (Worst) Module elements are unrelated Logical Cohesion : Elements perform similar activities as selected from outside module, i.e. by a flag that selects operation to perform (see also CommandObject). o i.e. body of function is one huge if-else/switch on operation flag Temporal Cohesion : operations related only by general time performed (i.e. initialization() or FatalErrorShutdown?()) Procedural Cohesion : Elements involved in different but sequential activities, each on different data (usually could be trivially split into multiple modules along linear sequence boundaries) Communicational Cohesion : unrelated operations except need same data or input Sequential Cohesion : operations on same data in significant order; output from one function is input to next (pipeline) Informational Cohesion: a module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure. Essentially an implementation of an abstract data type. o i.e. define structure of sales_region_table and its operators: init_table(), update_table(), print_table()

Functional Cohesion : all elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation o get_engine_temperature(), add_sales_tax()

Coupling (interdependence between modules) level names: (from worse to better, high coupling is bad)
y y y y y y

Content/Pathological Coupling : (worst) When a module uses/alters data in another Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag) Common/Global-data Coupling : 2 modules communicating via global data Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs. Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs. No data coupling : independent modules.