Uncle Bob Special Robert C. Martin 

Robert C. Martin a.k.a Uncle Bob 

SOLID Principles Principles of OOP 

SOLID • Single responsibility principle • Open / closed principle • Liskov substitution principle • Inteface segregation principle • Dependency inversion principle 

Single responsibility principle ױੌ ଼੐ ਗ஗ A class should have only a single responsibility (i.e. changes to only one part of the software's specification should be able to affect the specification of the class). A class should have only one reason to change. E.g A module complies and prints a report. It can be changed for two reasons: a) the content of the report could change or b) the format of the report could change. Pros It makes the class more robust. 

No content

Open / closed principle ѐߑ / ತࣧ ਗ஗ Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. A module will be said to be open if it is still available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs. A module will be said to be closed if [it] is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding). 

Open / closed principle package com.topjavatutorial; public class CreditCard { private int cardType; public int getCardType() { return cardType; } public void setCardType(int cardType) { this.cardType = cardType; } public double getDiscount(double monthlyCost){ if (cardType == 1) { return monthlyCost * 0.02; } else { return monthlyCost * 0.01; } } } Violation 

No content

Liskov substitution principle ѐߑ / ತࣧ ਗ஗ Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. • Contravariance of method arguments in the subtype. • Covariance of return types in the subtype. • No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype. A great example illustrating LSP (given by Uncle Bob in a podcast I heard recently) was how sometimes something that sounds right in natural language doesn't quite work in code. 

No content

Interface segregation principle ੋఠಕ੉झ ܻ࠙ ਗ஗ Many client-specific interfaces are better than one general-purpose interface. Pros It keeps a system decoupled and thus easier to refactor, change, and redeploy. E.g Xerox printer system 

Interface segregation principle public interface Order { void purchase(); void processPaypalPayment(); } public class OnlineOrder implements Order { … } public class InPersonOrder implements Order { …? } Violation 

No content

Dependency inversion principle ੄ઓҙ҅ ৉੹ ਗ஗ One should depend upon abstractions, [not] concretions. A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions. Pros Simpler to see a good thinking principle as a coding pattern Easy to mocking for testing 

No content

No content

Package Principles 

Package Principles Principles of package cohesion • Reuse-release Equivalence Principle (REP) • Common-Reuse Principle (CRP) • Common-Closure Principle (CCP) Principles of package coupling • Acyclic Dependencies Principle (ADP) • Stable-Dependencies Principle (SDP) • Stable-Abstractions Principle (SAP) 

The package must be created with reusable classes.
 “Either all of the classes inside the package are reusable, or none of them are.” The classes must also be of the same family. Classes that are unrelated to the purpose of the package should not be included. Pros
 A package constructed as a family of reusable classes tends to be most useful and reusable. Reuse-release Equivalence Principle 

CCP states that the package should not have more than one reason to change. If changes were to happen in an application dependent on a number of packages, ideally one only want changes to occur in one package, rather than in a number of them. This helps to identify classes that are likely to change, and package them together for the same reasons. If the classes are tightly coupled, they belong to the same package. Common-Closure Principle 

The CRP states that classes that tend to be reused together belong in the same package together. It is a way of helping to decide which classes belong in which package. When depending on a package, one wants to make sure that the classes are inseparable and interdependent, which is also handy when culling classes that do not belong in the package. Common-Reuse Principle 

In a development cycle with multiple developers, cooperation and integration needs to happen in small incremental releases. The ADP states that there can be no cycles in the dependency structure, and that when an incremental release is made, the other developers can adopt and build upon it. Acyclic Dependencies Principle 

No content

Breaking the Cycle. 1. Apply the Dependency Inversion Principle. We could create an abstract base class that has the interface that MyDialogs needs. We could then put that abstract base into MyDialogs and inherit it into MyApplication. This inverts the dependency between MyDialogs and MyApplication thus breaking the cycle. 2. Create a new package that both MyDialogs and MyApplication depend upon. Move the class(es) that they both depend upon into that new package. Acyclic Dependencies Principle 

No content

Designs, by nature of the environments they are used in or by, are changing. Thus, package design needs to support change as well. The SDP states that any packages one wants to be volatile should not be depended upon by a package that is difficult to change. Stable-Dependencies Principle 

The SAP says that a stable package should also be abstract, so that its stability does not prevent it from being extended. It also states that an unstable package should be concrete, since its instability allows the concrete code within it to be easily changed. Stable-Abstractions Principle 

Clean Architecture 

No content

Advantages Independent of Frameworks
 The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints. Testable
 The business rules can be tested without the UI, Database, Web Server, or any other external element. Independent of UI
 The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules. Independent of Database
 You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database. Independent of any external agency
 In fact your business rules simply don’t know anything at all about the outside world. 

Entities Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise. 

Use Cases The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case. 

Interface Adapters The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web. It is this layer, for example, that will wholly contain the MVC architecture of a GUI. The Presenters, Views, and Controllers all belong in here. The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views. 

Frameworks and Drivers The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards. 

Crossing boundaries Point inwards Dependency Inversion Principle Don’t pass Entities or DB rows Don’t violate Dependency Rule 

Is it Good for Us ? Let’s think about it. 

Thank you.