Refactor me if you dare

 

 Uncle Bob describes it as: "The ISP acknowledges that there are objects that require non-cohesive interfaces; however it suggests that clients should not know about them as a single class. Instead, clients should know about abstract base classes that have cohesive interfaces." After reading several documents and watching endless videos on this subject what I understand is that interface clients should not be forced to depend on methods that it doesn't use (giving those methods a null value).  Or in other words, it makes no sense to force a client to have a list of methods which return false, null or throw exceptions. Let's have a look at an example <?php // Interface Segregation Principle Violation interface HospitalFunctions { public function canGiveDiagnose (); public function diagnose (); public function administrateIVMedicine (); } class Doctor implements HospitalFunctions { public function canGiveDiagnose () { re...

After a week of holidays, here I am again, back to coding and learning. I really needed a rest but, on the other hand, after a couple of days, I was missing  my computer to bits. ¡Already the third letter of SOLID! Let's get into it. This complex to understand principle can be described as follows:  "If s  is a subtype of t , then we should be able to substitute objects of type  t  by objects of type  s   without altering the properties of the program."  In other words, it is possible to substitute a given object with an object of a sub-class and expect it to react the same way and fulfill its contract . But as usual, it is easier to understand if we have a look at a code snippet. Imagine our app currently sends all of our Notifications through Plain Text Email through SMTP.  Our code would look something like this: <?php $emailMessage = new EmailMessage( 'Laura' , 'New Blog Post' , 'Hi Laura, ...' ); $smtp = new SMTPTransport ( 'sm...

 Open for extension, closed for modification Described in its SOLID Principles by Uncle Bob as: "You should be able to extend the behavior of a system without having to modify that system." Just as in the case of the SRP, OCP is about minimizing the impact of changes in your software. Whether we are talking about re-usability within your code or the use of that code by others, it is a great advantage to be able to extend the features of your app without the need of modifying the whole thing. For example, imagine a feature which sends a notification email every time a new post is published in my blog. With a high level of coupling, I risk sending the notification after post publishing has failed.  How do we accomplish it?  Avoiding dependence upon specific implementations. Or better said, by using generic or abstract classes or interfaces that will be later defined in the final classes.  What is the difference between using an interface or an abstract class?  Int...

 This Object Oriented Programming principle states that each module or class should be responsible for only one part of the functionality.  By saying this, we are stating that each subsystem, module, class or function should have just one reason to change.  How do we accomplish this? By developing small service classes with enclosed objectives.  What is it that we want to accomplish through this strategy?   More cohesion and less resistance to change. Allow the composition of classes (or class injection) which deserves a extended post in this blog. Avoid duplicity and copy-pasting portions of code. Now, that seems fairly simple but, as with any theoretical principle, the problem is usually visualizing with an example what the theory is suggesting and, even more than that, in which cases should we apply this theory. Of course, it's not the same developing a small online shop for a cousin who produces and sells hand made costume jewelry, than developing  an a...