News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Paul Jones:
What's The Difference Between Tightly-, Loosely-, and De-Coupled ?
October 06, 2014 @ 10:20:30

In his latest post Paul Jones recounts a Twitter-based discussion that happened between Taylor Otwell (@taylorotwell) and others on Twitter about the different types of coupling in libraries or applications. The discussion focused around three different types and their definitions: loosely-coupled, tightly-coupled and de-coupled.

The quotes from the conversation come from Taylor, but Paul includes some of his own thoughts in response (things better expressed in more than 140 characters. He talks about some of the assumptions that were made during the discussion, the general knowledge level of "basic programming terminology" and how Paul views the definition of "decoupled".

If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. [...] The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

He talks about how one of the main goals of the packages that make up the Aura project is to be decoupled from the start and how that can help with changing requirements/dependencies down the road. He also defines what he sees as "loose" and "tight" coupling, largely defined by the packages required in the "composer.json".

0 comments voice your opinion now!
decouple loose tight coupling package library definition terminology

Link: http://paul-m-jones.com/archives/6051

Matthieu Napoli:
Decoupling packages
September 26, 2014 @ 13:42:24

In a recent post to his site Matthieu Napoli looks at some first steps you can take to help decouple packages in your application. He describes a few considerations and methods to think about as you try to break those chains.

Decoupling packages is a hard thing. There are not a lot of options, and this blog post is about how some options are better than others.

Let's say for example that you are writing a "package", or library, to respond to HTTP requests (that kind of package could be considered the basis for a web framework). How do you handle routing? If you write your Router package as an independent package (which is good: small and specialized packages are more reusable and maintainable), you might not want to couple the HTTP package to the Router package: you want to leave users free to choose the router of their choice. So, what are your options to make the HTTP package and the Router package decoupled from each other?

He looks at a few different approaches including focusing on event-driven programming or splitting things along "edges" and making interfaces/adapters to hook them together. He also puts an emphasis on standardizing interfaces, even those outside of your own internal to the application (think the set of PHP PSRs).

0 comments voice your opinion now!
decouple package event interface adapter standardized

Link: http://mnapoli.fr/decoupling-packages/

Matthias Noback:
Decoupling your (event) system
August 26, 2014 @ 11:15:17

Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.

0 comments voice your opinion now!
decouple event manager dispatch handling symfony adapter object

Link: http://php-and-symfony.matthiasnoback.nl/2014/08/symfony2-decoupling-your-event-system/

Matthias Noback:
Symfony2 How to create framework independent controllers?
June 18, 2014 @ 09:15:16

Matthias Noback has a new post to his site today, the first part of a series, looking at making framework-independent controllers for use in a Symfony2 framework-based project.

The general belief is that controllers are the most tightly coupled classes in every application. Most of the time based on the request data, they fetch and/or store persistent data from/in some place, then turn the data into HTML, which serves as the response to the client who initially made the request. [...] In this post I demonstrate that this high level of coupling is definitely not necessary. I will show you how you can decrease coupling a lot by taking some simple steps. We will end with a controller that is reusable in different types of applications, e.g. a Silex application, or even a Drupal application.

In this first part he focuses on a few places where the common practices lead to some unnecessary coupling between the controller and framework:

  • Using the framework helper methods
  • Using dependency injection (manually injecting instead)
  • Making the controller a service instead

The next post in the series will look at the use of annotations and how to refactor them out of the controller to remove yet another coupling point.

0 comments voice your opinion now!
framework independent controller symfony2 tutorial refactor decouple

Link: http://php-and-symfony.matthiasnoback.nl/2014/06/how-to-create-framework-independent-controllers/

Wojciech Sznapka:
Software developers care too much about tools
April 29, 2014 @ 09:17:24

In his latest post Wojciech Sznapka suggests that software developers care too much about tools and not enough about software quality and structure.

Lately I see perilous situation in software development area. There are plenty of good devs so much bounded to tools. By tools, I mean mostly frameworks. [...] First of all, we all need to admit, that quality of modern MVC framework raised a lot, comparing with state of things few years ago. [...] On the other hand, there's huge temptation to write own frameworks, ignoring the great work of community.

He talks about more of the benefits of using a framework but instead of being dependent on it for your application, make it just another tool. He recommends quality, decoupled and well-designed code separate from the framework. Additionally, he suggests using things like domain driven design to encourage reusability and accurately modeled business needs in the code.

0 comments voice your opinion now!
software tools framework decouple domainmodel opinion

Link: http://blog.sznapka.pl/software-developers-care-too-much-about-tools

Kristopher Wilson:
Decoupling the Framework
December 02, 2013 @ 12:19:36

Kristopher Wilson has a new post to his site talking about something that could be very difficult with an existing application (and a good starting place for a new one) - decoupling from the framework. He advocates that your application shouldn't be an extension of the framework, more so a user of it to make it potentially easy to replace.

We spend a lot of time discussing and analyzing the features and merits of several frameworks, trying very hard to make sure we find the perfect one to use for our project. Rightfully so: picking the wrong framework can lead to a slew of issues down the road in terms of maintenance and scalability. [...] We also spent a considerable amount of effort making sure that there is minimal amount of coupling within our code. Strong coupling leads to problems testing, adapting, refactoring and reusing code. What if we applied that same principal to dealing with whatever framework we're using?

He goes on to look at the "framework is not your application" concept and fleshes it out with examples of it applied to a few different topics: Controllers, Models and ORMs. He also shows how, through the use of something like Doctrine's EntityManager, you can easily abstract things out so the internals of the application can easily split the application and framework.

0 comments voice your opinion now!
decouple framework controller model orm doctrine entity

Link: http://kristopherwilson.com/2013/11/27/decoupling-the-framework/

Benjamin Eberlei:
Decoupling from Symfony Security and FOSUserBundle
September 05, 2013 @ 10:37:43

Benjamin Eberlei has posted some of the results of his work at decoupling Symfony security from the FOSUserBundle, one of the "Friends of Symfony" packages that provides easy user management in your application.

In this blog post I will show how to decouple your core application from the Symfony Security component and User bundles such as the FOSUserBundle. [...] This blog post will add another perspective on how to achieve decoupling from Symfony user and security with a very simple approach. With this puzzle piece and others I wrote about before (Controllers as Service, Param Converters) and other pieces I still need to write about, I would classify Symfony2 as a good framework.

He talks about some of the dependencies this bundle introduces and one way to mitigate it by extending the User object with your own custom entities. His example is a "Customer" entity that only defines the "id" and "username" properties.

0 comments voice your opinion now!
symfony security fosuserbundle decouple example

Link: http://www.whitewashing.de/2013/09/04/decoupling_from_symfony_security_and_fosuserbundle.html

NetTuts.com:
How to Write Code That Embraces Change
February 04, 2013 @ 13:18:58

On NetTuts.com today there's a great new article about how to write code that embraces change and can be easily updated and reconfigured due to a decoupled nature and use of good OOP concepts.

Writing code, which is easy to change is the Holy Grail of programming. Welcome to programming nirvana! But things are much more difficult in reality: source code is difficult to understand, dependencies point in countless directions, coupling is annoying, and you soon feel the heat of programming hell. In this tutorial, we will discuss a few principles, techniques and ideas that will help you write code that is easy to change.

He covers some of the good OOP principles to think about when developing - like cohesion, orthogonality and coupling (via class methods, polymorphism, dependency injection or interfaces). He spends some time looking at the SOLID development principles and how you can implement each of them in some sample code. He also talks some about high level design and how the separation of concerns can help make your code easier to maintain and change.

0 comments voice your opinion now!
tutorial code change oop decouple dependency solid principles


PHPMaster.com:
Living Apart Together Decoupling Code and Framework
November 29, 2012 @ 09:32:21

On PHPMaster.com today there's a new post (by Remi Woler) that looks at abstraction and keeping functionality out of the framework and more decoupled in case the need for switching environments/frameworks comes up.

Of course you develop using the latest technologies and frameworks. You've written 2.5 frameworks yourself, your code is PSR-2 compliant, fully unit-tested, has an accompanying PHPMD and PHPCS config, and may even ship with proper documentation (really, that exists!). When a new version of your favorite framework is released, you've already used it in your own toy project and submitted a couple of bug reports, maybe even accompanied with a unit test to prove the bug and a patch that fixes it. If that describes you, or at least the developer you want to be: reconsider the relationship your code has with the framework.

He talks some about the dependencies most code written today has on the frameworks it lives in and how a good project design can make it easier to decouple this relationship. He suggests using things like wrapper classes (think "services") to abstract out the functionality to custom components. It's these components that handle the work, just reporting back the results to the controller/model that called them.

0 comments voice your opinion now!
decouple code framework tutorial module wrapper


Jani Hartikainen's Blog:
Decoupling models from the database Data Access Object pattern in PHP
January 05, 2009 @ 21:22:26

In this new post to his blog Jani Hartikainen looks at implementing the Data Access Object pattern in your PHP applications.

The advantage of this is that you can easily implement different methods to persist objects without having to rewrite parts of your code. I'm again going to use the programming language quiz game I wrote as an example. Since I initially wrote it to use Doctrine ORM directly, and both the old and new code are available, you can easily see how the code was improved.

He starts off with a look at the pattern itself (including a diagram of how an example would work with Doctrine) followed by the creation of the models for his Questions example. Add in the factory to create an instance and an exmaple of it in action and you're there.

0 comments voice your opinion now!
decouple model data access object designpattern tutorial doctrine



Community Events





Don't see your event here?
Let us know!


interview deployment laravel zendserver update podcast tips introduction library language list symfony release opinion community framework package install api series

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework