Software that requires an enormous amount of changes to implement one new feature or fix a bug is unstable and should be considered as "bad". Software should be designed so, that in case of a new feature, no existing classes should have to change. In other words: it is closed for modification. Existing software may be extended to achieve new features however.

He starts off with a "What" section explaining a bit more about what this open/closed means for your code and gets into an example showing it in a more practical way. He shows how to take the principle and refactor an API connector class to pass in the object it needs (Bike) and use that to get information (rather than just passing in the data). He uses a Factory to get the object type he needs based on the Bike type.

The single responsibility principle isn't all that hard to explain. It states that an object should do one thing, and one thing only. [...] A responsibility is a reason to change, and a class should only have one of those. Now all of this may sound abstract and since the objective of this series is to avoid just that we'll just dive into the why now.

He includes some sample code to illustrate, going with an active record implementation, some of the problems that come with a typical setup including issues with unit testing, bad practice of using the data store directly, etc. He shows a refactored code example that splits out the functionality previously all in the one class ("Bike") into three different ones - one is the normal Bike object, another compares the Bikes and the third works with the data store to handle the CRUD for the objects.

So many languages share fundamental principles, and indeed many are even derived from the same concepts, but because they differ in their approach there's something new to understand in each. It's these differences that will frequently bolster your understanding of your primary language, or indeed of programming as a whole.

He notes that it's not just PHP developers that pigeon hole themselves into one language - developers on other languages do to. He recommends they lift their heads up and branch out and stop attacking other languages with "language X is best" articles.

It's stepping outside of your comfort zone and engaging with the underlying concepts of the languages and tools you are using that will enable you to grow as a developer.

As much as we're like to believe that "loose coupling, high cohesion" is enough, when you actually dive into the concept, you find that it's more descriptive than prescriptive. If you want to know how to actually apply these to your day to day development, you have to get into the SOLID principles which describes the five tangible aspects that "good" OO design should contain.

He goes through each of the five principles in the list, describing what they are and, for some, including a bit of sample code to make the point clearer:

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

While studying for the advanced software engineering exam at PoliMi, I discovered there is also a set of principles akin to SOLID for the design of packages, and not only of classes and interfaces. Uncle Bob published them after the SOLID series. Note that package here can be intended as a zip or any deliverable binary unit, not necessarily as a PHP namespace or Java package, or a source folder. [...] In fact, I think that PHP namespaces will play the role of packages soon, as they provide a mechanism for encapsulation: use statements are not necessary when you refer to entities in the same namespace, just like java imports.

These three additional principles (CCA) are:

• CRP: Common Reuse Princple
• CCP: Common Closure Principle
• ADP: Acyclic Dependencies Principle

Check out the rest of the article for their full descriptions.

• Use PHP Only When You Need it - Rasmus Lerdorf
• Use Many Tables With PHP and MYSQL for Scalability - Matt Mullenweg
• Never, ever trust your users - Dave Child
• Invest in PHP Caching - Ben Balbo
• Speed up PHP Development with an IDE, Templates and Snippets - Chad Kieffer
• Make Better Use of PHP's Filter Functions - Joey Sochacki
• Use a PHP Framework - Josh Sharp
• Don't use a PHP Framework - Rasmus Lerdorf
• Use Batch Processing - Jack D. Herrington
• Turn on Error Reporting Immediately - David Cummings

Some of them are conflicting, but that just means that you'll have to do what you've always done - take advice with a grain of salt and ultimately decide what's best for you and your application.

On the old site, I started a series of tutorials named "PHP Application Design". I planned for at least three parts, and while I did publish the first two and wrote at least half of part three, I found myself out of time to make it to the finish. Still dedicated to writing reusable and extensible PHP code and spreading the knowledge, this is a restart of the series, renamed as simply "OO PHP"

In part one he looks at the basics of OOP (terms, defining properties/methods, autoload, exceptions, type hinting, etc) with some code examples sprinkled through out. Part two looks at the "boring OOP principles" like polymorphism, encapsulation and heuristics.