Quotes About Principle

My master Thomas More would give anything to anyone. Some say that's good and some say that's bad, but I say he can't help it and that's bad... because some day someone's going to ask him for something that he wants to keep; and he'll be out of practice.

Epicurus ... supposes not only all mixt bodies, but all others to be produced by the various and casual occursions of atoms, moving themselves to and fro by an internal principle in the immense or rather infinite vacuum.

Being told by way of aggravation, that he had eaten half a dozen plumbs, Nay truly, sister, (answers he simply to her) I have eaten half a score. So perfect an enemy was he to a lie, that he had rather accuse himself of another fault, than be suspected to be guilty of that.

There is an ongoing battle between conscience and self-interest in which, at some point, we have to take sides.

Sometimes, to do the right thing, we must keep a promise we never made.

As far as I can see, materialism is a view that has no very compelling argument in its favor and that is confronted with very powerful objections to which nothing even approaching an adequate response has been offered. The central objection, elaborated in various ways below, is that the main materialist view, quite possibly the only serious materialist view, offers no account at all of consciousness and seems incapable in principle of doing so.

SRP is one of the more important concept in OO design. It's also one of the simpler concepts to understand and adhere to. Yet oddly, SRP is often the most abused class design principle.

The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.

if I must encode either the interface or the implementation, I choose the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable to encoding the interface.

abstraction is evil. Code is anti-evil, and clean code is perhaps divine.

Never mention the name of anything concrete and volatile. This is really just a restatement of the principle itself.

THE STABLE ABSTRACTIONS PRINCIPLE A component should be as abstract as it is stable.

The Stable Abstractions Principle (SAP) sets up a relationship between stability and abstractness. On the one hand, it says that a stable component should also be abstract so that its stability does not prevent it from being extended. On the other hand, it says that an unstable component should be concrete since its instability allows the concrete code within it to be easily changed.

OCP: The Open-Closed Principle Bertrand Meyer made this principle famous in the 1980s. The gist is that for software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.

LSP: The Liskov Substitution Principle Barbara Liskov's famous definition of subtypes, from 1988. In short, this principle says that to build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another.

software artifact should be open for extension but closed for modification.

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 Reuse/Release Equivalence Principle (REP) is a principle that seems obvious, at least in hindsight. People who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and are given release numbers.

THE COMMON CLOSURE PRINCIPLE Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons.

This is the Single Responsibility Principle restated for components. Just as the SRP says that a class should not contain multiples reasons to change, so the Common Closure Principle (CCP) says that a component should not have multiple reasons to change.

The Open-Closed Principle (OCP) was coined in 1988 by Bertrand Meyer.1 It says: A software artifact should be open for extension but closed for modification.

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

Transitive dependencies are a violation of the general principle that software entities should not depend on things they don't directly use. We'll encounter that principle again when we talk about the Interface Segregation Principle and the Common Reuse Principle.