Quotes About Dependency

If we tried to design the component dependency structure before we designed any classes, we would likely fail rather badly. We would not know much about common closure, we would be unaware of any reusable elements, and we would almost certainly create components that produced dependency cycles.

the fact that oo languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted

It is the perversity of software that a module that you have designed to be easy to change can be made difficult to change by someone else simply hanging a dependency upon it.

ISP: The Interface Segregation Principle This principle advises software designers to avoid depending on things that they don't use.

DIP: The Dependency Inversion Principle The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.

The source code of higher-level services must not contain any specific physical knowledge (e.g., a URI) of any lower-level service.

THE COMMON REUSE PRINCIPLE Don't force users of a component to depend on things they don't need.

If component A should be protected from changes in component B, then component B should depend on component A.

THE ACYCLIC DEPENDENCIES PRINCIPLE Allow no cycles in the component dependency graph.

The OCP is one of the driving forces behind the architecture of systems. The goal is to make the system easy to extend without incurring a high impact of change. This goal is accomplished by partitioning the system into components, and arranging those components into a dependency hierarchy that protects higher-level components from changes in lower-level components.

If we tried to design the component dependency structure before we designed any classes, we would likely fail rather badly. We would not know much about common closure, we would be unaware of any reusable elements, and we would almost certainly create components that produced dependency cycles. Thus the component dependency structure grows and evolves with the logical design of the system.

One sure way to make a software component difficult to change, is to make lots of other software components depend on it.

The LSP makes clear that in OOD the ISA relationship pertains to behavior . Not intrinsic private behavior, but extrinsic public behavior; behavior that clients depend upon.

The diagram in Figure 14.5 shows X, which is a stable component. Three components depend on X, so it has three good reasons not to change. We say that X is responsible to those three components. Conversely, X depends on nothing, so it has no external influence to make it change. We say it is independent.

Figure 14.6 shows Y, which is a very unstable component. No other components depend on Y, so we say that it is irresponsible. Y also has three components that it depends on, so changes may come from three external sources. We say that Y is dependent.

More precisely, the Law of Demeter says that a method f of a class C should only call the methods of these: • C • An object created by f • An object passed as an argument to f • An object held in an instance variable of C

When the I metric is 1, it means that no other component depends on this component (Ca = 0), and this component does depend on other components (Ce > 0). This is as instable as a component can get; it is irresponsible and dependent. Its lack of dependents gives it no reason not to change, and the components that it depends on may give it ample reason to change.

For example, maybe you like Spring. Spring is a good dependency injection framework. Maybe you use Spring to auto-wire your dependencies. That's fine, but you should not sprinkle @autowired annotations all throughout your business objects. Your business objects should not know about Spring. Instead, you can use Spring to inject dependencies into your Main component. It's OK for Main to know about Spring since Main is the dirtiest, lowest-level component in the architecture.

Dependent Functions. If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible.

You must understand that when you marry a framework to your application, you will be stuck with that framework for the rest of the life cycle of that application. For better or for worse, in sickness and in health, for richer, for poorer, forsaking all others, you will be using that framework. This is not a commitment to be entered into lightly.

I say, why start from nothing if you can start with everything? We've already got a civilization.' 'No. We haven't. We're just living on the edge of someone else's, like fleas on a dog's back. If the dog drowns, the fleas drown, too.

What starts as gratitude quickly becomes dependency and ends as entitlement

it is human nature that what starts as gratitude quickly becomes dependency and ends as entitlement.

Thirty years ago, the average British household contained enough food to last eight days; today the average is two days. It is no exaggeration to say that London, at any time, exists only six meals away from starvation.