Quotes from Robert C. Martin

SRP: The Single Responsibility Principle An active corollary to Conway's law: The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change.

Il campo @author di un Javadoc ci dice chi siamo. Siamo gli autori. E una caratteristica degli autori è che hanno dei lettori. In effetti, è responsabilità degli autori riuscire a comunicare bene coi loro lettori. La prossima volta che scriverete una riga di codice, ricordatevi che voi ne siete gli autori, e che scrivete a dei lettori che vi giudicheranno per quello che avrete scritto.

A good architect maximizes the number of decisions not made.

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.

One of the more common motivations for writing comments is bad code.

Don't hide side effects with a name. Don't use a simple verb to describe a function that does more than just that simple action.

The topmost parts of the source file should provide the high-level concepts and algorithms. Detail should increase as we move downward, until at the end we find the lowest level functions and details in the source file.

Standards make it easier to reuse ideas and components, recruit people with relevant experience, encapsulate good ideas, and wire components together. However, the process of creating standards can sometimes take too long for industry to wait, and some standards lose touch with the real needs of the adopters they are intended to serve.

dynamically linked files, which can be plugged together at runtime, are the software components of our architectures.

So, when and why should we use UML? Diagrams are most useful for communicating with others and for helping you work out design problems.

three principles of component cohesion: • REP: The Reuse/Release Equivalence Principle • CCP: The Common Closure Principle • CRP: The Common Reuse Principle

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.

Os padrôes facilitam a reutilização de ideias e compomentes, recrutam pessoas com experiência considerável, encapsulam boas ideis e conectam os compomentes. Entretanto, o processo de criação de padôes pode, ás vezes, ser muito longo para que o mercado fique á espera deles, e alguns padrôes acabam se desviando das necessidades reais das pessoas a quem eles pretendem servir.

Classes and modules that are grouped together into a component should be releasable together. The fact that they share the same version number and the same release tracking, and are included under the same release documentation, should make sense both to the author and to the users.

When we think of a software architect, we think of someone who has power, and who commands respect.

As you mature in your profession, your error rate should rapidly decrease towards the asymptote of zero.

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.

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.

the architecture of a system has very little bearing on whether that system works. There are many systems out there, with terrible architectures, that work just fine. Their troubles do not lie in their operation; rather, they occur in their deployment, maintenance, and ongoing development

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.