I love theory of programming I’m a perfectionist, I look for most efficient ways of coding Implementing a prototype in Web
Ask the audience
Coincidental – Grouped at random, nothing relates the parts, eg Frequently used functions Logical – Grouped because they are logically categorized to do the same thing even if different, eg grouping IO functions (url is different to local file) Procedural – Grouped by order of when things happen, eg checking file permissions then opening it Communicational – Grouped because they operate on the same data Functional - Grouped because they all contribute to a single well-defined task of the module (Single Responsibility Principle in Action!)
Remember Rigidity and Fragility?
Flow of Dependencies is opposite to Flow of Control
Remember the DI Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
There are different types of Dependency Injection, Constructor Injection is simplest.
Other ways: Factory Method Services Locator Interface Injection
Count the dependencies.
Step 1: Create objects elsewhere
Now how many dependencies does the class have?
Plugins are perfect examples of IOC
Boundaries? - Enable reusability, because things are modular Invert Dependencies? - Enable interchangablility by allowing mix and match (“plugin principle”)
How does IOC help? How do we do it?
When should we apply it? Theoretical: Whenever one class depends on another. Practical: Pick clear boundaries and decouple them
Inversion of control
Inversion of Control
And the Dependency Inversion Principle
The Dependency Inversion Principle
“High-level modules should not depend on low-level
modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should
depend on abstractions.”
The “Plugin Principle”
“Good” and “Bad” Design
Cohesion and Coupling
Inversion of Control
What is it?
Characteristics of “Bad” Design
Difficult to change because a change affects other parts
One change causes unexpected breaks
Difficult to reuse – tied to specific implementation
The Big Ones (Good Code)
Example of Low Cohesive Code
Included are 35+ functions that provide you with the ability
to [use] a nicely formatted var dump, validate emails, generate
random strings, flatten an array, pull a single column out of a
multidimensional array and much more!
Util::ity.php – every programmers little buddy
● Content Coupling
● Control Coupling
● Stamp Coupling
● Data Coupling
● Message Coupling
One class directly manipulates another's
data, so a change in the data means a
change in the other class too
Two modules share the same global data
(e.g. a global variable). Changing the
shared resource implies changing all the
modules using it
One module controlling the logic of another,
by passing it information on what to do
(e.g. passing a what-to-do flag)
Stamp (Data-Structured) Coupling
Modules both use a common data structure
and use only a part of it. Can lead to
unexpected breaks when data structure
Objects share data through parameters
$mailer = new Mailer();
$mailer->sendEmail($to, $from, $body);
Objects use a public interface to exchange
messages (events, observer pattern)
Objects don’t know about each other and
never communicate with each other.