I would like to start this section by quoting from the famous book “Design Patterns, Elements of Reusable Object-Oriented Software” by the “Gang of Four” Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
The book starts with this meaningful discussion – “Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships among them. Your design should be specific to the problem at hand but also general enough to address future problems and requirements. You also want to avoid redesign, or at least minimize it. Experienced object-oriented designers will tell you that a reusable and flexible design is difficult if not impossible to get “right” the first time. Before a design is finished, they usually try to reuse it several times, modifying it each time.

Yet experienced object-oriented designers do make good designs. Meanwhile, new designers are overwhelmed by the options available and tend to fall back on non-object-oriented techniques they’ve used before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don’t. What is it?”
This introductory paragraph ends with a question mark. I will always encourage you to read the book itself; a must read, however, at the same time I would like to start our discussion keeping this question mark in the background – “Experienced designers evidently know something inexperienced ones don’t. What is it?”
I have no doubt that “Single Responsibility Principle” or SRP is one of the most important concepts in object-oriented design, which experience designers know and follow from the beginning, and the inexperienced designers do not understand that core concept . And, it makes a real big difference.
Let us start with the core concept that sits right in the heart of SRP – classes should not do far too many things. Yes, a class can do many things for an object; but, you cannot abuse that power. It could cause unexpected harm to the organization of code in general. When a gentle tap with a hammer works fine, why strike the nail with a huge force? It may have a boomerang effect.
Thinking before and designing properly is entirely a different activity than getting the software to work. We always try to make our code work fast; keeping no rooms for organization and cleanliness. It’s a wrong approach and it causes a lot of harm to the effectiveness as a whole. When the program works, we are done; we forget that maintaining a separation of concerns is as important an activity in our programming design as it is in the running program. The real problem starts with the overstuffed classes that are burdened with too many tasks. They are not “decoupled units” with single responsibility principles. Large numbers of small, single-purpose classes are like many caskets with well-defined-labels; this type of organization makes our tasks easier to find the appropriate things than dumping all staff in one single casket.
So we need many small classes, not a few large ones staffed with too many tasks. Each small class should have single responsibility encapsulated in a way so that they have the single reason to change. They will also communicate with a few other small classes to get the desired result. In the final chapter, we will build a MVC patterned framework keeping these single responsibility principles and separation of concerns intact.
Hopefully, you have started guessing how does Composer fit into this big picture. Actually, that is the reason why every good PHP framework such as Symfony or Laravel depends on this dependency management system. What is more, Composer has now become the standard of dependency management.
You can always use Composer project wise. Although, it is always good to install it in your system globally so that you can run it anywhere in your system. Let us install it globally. For any Debian based Linux distribution it is simple.
//code 3.1
ss@ss-Lenovo-3000-G530:/$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
ss@ss-Lenovo-3000-G530:/$ php -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
Installer verified
ss@ss-Lenovo-3000-G530:/$ php composer-setup.php
All settings correct for using Composer

Composer (version 1.6.5) successfully installed to: //composer.phar
Use it: php composer.phar

ss@ss-Lenovo-3000-G530:/$ sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
All settings correct for using Composer

Composer (version 1.6.5) successfully installed to: /usr/local/bin/composer
Use it: php /usr/local/bin/composer

In the first half, I have downloaded the Composer installer in my root directory and I have verified the product. After that I have chosen the directory “usr/local/bin/composer” to set it up so that I can use it globally.
Next, I will check whether it works or not.
In “var/www/html” directory I have created a folder called “test-composer” and initialize the newly-installed composer into it.
//code 3.2
ss@ss-Lenovo-3000-G530:/var/www/html/test-composer$ composer init

Welcome to the Composer config generator

This command will guide you through creating your composer.json config.

Package name (/) [root/test-composer]: ss/mvc
Description []: mvc
Author [, n to skip]: n
Minimum Stability []: stable
Package Type (e.g. library, project, metapackage, composer-plugin) []: project
License []:

Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? y
Search for a package: cocur/slugify
Enter the version constraint to require (or leave blank to use the latest version):
Using version ^3.1 for cocur/slugify
Search for a package:
Would you like to define your dev dependencies (require-dev) interactively [yes]?
Search for a package:

"name": "ss/mvc",
"description": "mvc",
"type": "project",
"require": {
"cocur/slugify": "^3.1"
"minimum-stability": "stable"

Do you confirm generation [yes]? Y

I have successfully created a “composer.json” file inside the test folder. Now, I can install Composer.
//code 3.3
ss@ss-Lenovo-3000-G530:/var/www/html/test-composer$ composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Installing cocur/slugify (v3.1): Downloading (100%)
Writing lock file
Generating autoload files

Composer has been successfully installed. We can check the directory listing.
//code 3.4
ss@ss-Lenovo-3000-G530:/var/www/html/test-composer$ ls
composer.json composer.lock vendor

Now, you can use the “slugify” object to convert your any string into a slug. It can provide a good support to our MVC patterned framework. Not only that, we need to leverage the resources of other useful packages, available in “Packagist – The PHP Package Repository” (https://packagist.org/).
Solving every problem from first principles is not a good idea at all. Effective patterns always reuse solutions that have worked for them in the past so that we can use it again and again. The combination of Composer and other PHP Packages solves a great problem that we have faced over the time.
There are recurring patterns of classes and communicating objects in many object-oriented systems, however, the availability of these patterns was extremely scarce in the past. We didn’t do enough job of recording experiences for others to do. If they did, there would not have been a good common resource to pull recurring patterns from it.
Using the combination of Composer and Packagist now we can not only find a package, we can also find all its dependencies and related packages. Even PEAR packages are there to assist your project’s decision-making process.