The Audience Persistence Module - Audience include DBAs and software architects. Reporting Module - Audience include clerks, accountants, and operations. Payment Computation Module for a Payroll System - Audience may include lawyers, managers, and accountants.

Roles and Actors So a responsibility is a family of functions that serves one particular actor. (Robert C. Martin)

Source of Change An actor for a responsibility is the single source of change for that responsibility. (Robert C. Martin

Objects That Can "Print" Themselves Objects That Can "Save" Themselves

do you have seen code like this? what is wrong here? is this a SOLID?

hmmm… do we need Auth::check() in this controller? What if this was API? Or what if we run this from command line

A database call ? Ask your self, do I need to this here? who will ask this to change? A business, designer or DBAdmin What if boss decide to switch database from MySQL to MongoDB ?

hm…. HTML… A spaghetti code ? Who will ask to change this? Designer…are you the designer ? What if we have multiple implementation…. For example: Web/HTML, Console… or Mobile…iOS..

hm…. Is this more clean…. What we have here… Repository PHP 5 introduces type hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype), interfaces, arrays (since PHP 5.1) or callable (since PHP 5.4).

Interface…yes, but for this example we don’t expect database changes. Repository will connect Factories with Gateways (persistence). Decoupled architecture Pros: Separation of concerns; the application need not know about or track any or all data sources. Allows easy unit testing as the repositories are bound to interfaces which are injected into classes at run time. DRY (Dont Repeat Yourself) design, the code to query and fetch data from data source(s) is not repeated. Cons: Adds another layer of abstraction which adds a certain level of complexity making it an overkill for small applications.

- HTML implementation of the Interface

TEXT implementation of the Interface

And this hit the Open/Close principies

The Open/Closed Principle, OCP in short, is credited to Bertrand Mayer, a French programmer, who first published it in his book n Object-Oriented Software Constructionin 1988.

The principle rose in popularity in the early 2000s when it became one of the SOLID principles defined by Robert C. Martin in his book Agile Software Development,

31.
A. High-level modules should not depend
on low-level modules. Both should depend
on abstractions.
B. Abstractions should not depend upon
details. Details should depend upon
DEPENDENCYINVERSIONPRINCIPLE
Dependency inversion
principle