jacopo beschi: yet another web guy

Posts Archive

SOLID Design principles and Php: Dependency inversion

Created at: Mar/11/2014 jacopo beschi

This is the last article about the SOLID principles series. In this article we talk about the D in SOLID: "Dependency inversion". This last part may be the harder to understand for you guys. Before saying the principle we need to explain some definitions: - High level code: the code that is focused on solving a general problem (For example db access) - Low level code: the code focused on solving a particular problem.

Read on

SOLID Design principles and Php: Interface Segregation

Created at: Feb/24/2014 jacopo beschi

Ok guys we're almost done with the SOLID principles series, today we talk about the interface segregation principle. The Interface segregation principle says: "A client should not be forced to implement and interface that doesn't use". As we are used let's explain that with an example. Imagine we are using the repository pattern to save some objects.

Read on

Laravel setup alias and service provider in a package

Created at: Feb/17/2014 jacopo beschi

Hello folks. This article is just a brief explanation on how you can create new run-time alias and load service provider within your laravel package. If you want to load other service provider from the package you have to use this command inside the register method if your service provider:

Read on

SOLID Design principles and Php: Liskov substitution

Created at: Feb/10/2014 jacopo beschi

Hello everybody, today we talk about the third letter (L) of SOLID principles: Liskov substitution. This principle has a mathematical definition pretty hard to understand, but in practise it says: every time you create a subclass of a superclass that subclass should be substitutable in every place where the original class took place. Let's dig in with an example. Imagine we create a player class.

Read on

SOLID Design principles and Php: Open closed

Created at: Jan/28/2014 jacopo beschi

In this article we talk about the O in SOLID principles: Open closed. The Open closed principle says that: a class should be open for extension but closed for modification, what that means? Well, in practise when you make a class you could expand it for adding new features but not modify it for changing his beahvior, instead you should separate the extensible behavior behind an interface and flip the dependencies. What that means? I'll drive into that with an example. Let's say we are writing a business application to handle building information in a certain country. Let's create a class to handle small apartments:

Read on