

MyBuilder Tech Blog:
Insertion, Removal and Inversion Operations on Binary (Search) Trees in PHP
Jul 22, 2015 @ 10:08:21

The MyBuilder.com Tech blog has a tutorial posted showing you how to work with binary trees in PHP, specifically how to perform insertion, removal and inversion operations on their data.

Recently Max Howell (creator of Homebrew) posted an interesting tweet in regard to Google's interview process. In this tweet he mentioned how one of the proposed questions was to white-board a solution to invert a binary tree. Over the past couple of years I have been interested in exploring fundamental Computer Science data-structures and algorithms. As a result, I thought it would be interesting to explore this structure and associated operations in more depth - using immutable and mutable PHP implementations to clearly highlight the benefits garnered from each approach.

He starts with a brief definition of what a binary search tree is just to be sure everyone is on the same page. He then gets into the code to represent a Node, a simple class that has a value and "left" and "right" variables to contain each of the possible two child nodes. He then goes through each of the operations (insertion, removal and inversion) showing code examples for both mutable and immutable methods.

tagged: binarytree insertion removal inversion mutable immutable

Link: http://tech.mybuilder.com/insertion-removal-and-inversion-operations-on-binary-search-trees-in-php/

Laravel News:
5 Resources to Learn about the Laravel IoC Container
Jan 02, 2015 @ 10:04:59




tagged: laravel inversion control ioc container dependency injection tutorials


Matthias Noback:
Composer "provide" and dependency inversion
Oct 06, 2014 @ 09:53:20

Matthias Noback has a new post today responding to a recent post talking about virtual packages with Composer (using "provide") and some of his own thoughts of how it relates to dependency inversion.

This is a response to Peter Petermann's article Composer and virtual packages. First, let's make this totally clear: I don't want to start an Internet war about this, I'm just pointing out some design issues that may arise from using Composer's provide option in your package's composer.json file. [...] Yes, if a user wants to run the code in your library, they need to have some class that implements [the "provides" requirement]. But no, this shouldn't be reflected in the dependencies of the library. Let me explain this by taking a look at the Dependency inversion principle.

He gives an example of using a specific package for logging (the Zend logger) and how that hard-coded dependency can be refactored out using one of two methods: either a custom interface or one described elsewhere. Getting back to "provide", he lists some reasons why he thinks that defining the interface itself in the Composer configuration is a good idea. These include:

  • Strictly speaking (as in, would the code compile), the code from the library itself [...] just needs the LoggerInterface (which happens to be in the psr/log package).
  • By depending on an implementation package, you basically undo any effort you made to depend on abstractions and not on concretions.
  • Some day, someone may decide to introduce another virtual package, called the-real-psr/log-implementation.
  • The notion of an "implementation package" is really vague. What does it mean for a package to be an implementation package.

Each of the reasons has a bit of description to go along with it. He also points out an interesting example where the package actually knows about existing virtual package, the DoctrinePHPCRBundle and its use of "jackalope" and "phpcr".

tagged: composer dependency inversion provide configuration interface

Link: http://php-and-symfony.matthiasnoback.nl/2014/10/composer-provide-and-dependency-inversion/

SOLID: Part 4 - The Dependency Inversion Principle
Feb 14, 2014 @ 11:53:22

NetTuts.com has posted the next part in their series (the looking at the SOLID development principles discussing the Dependency Inversion Principle, the final letter in the "SOLID" acronym.


They start off with a basic definition of the dependency inversion principle and an example of it in a more real world situation. They use it to separate out the handling of reading and rendering PDFs and eBooks. It's just some basic code, no real functionality, but it gives you an idea of how to architect the application.

tagged: dependency inversion principle solid development part4 series

Link: http://code.tutsplus.com/tutorials/solid-part-4-the-dependency-inversion-principle--net-36872

Brandon Savage:
The "D" Doesn’t Stand For Dependency Injection
Aug 13, 2013 @ 11:03:55




tagged: solid oop development dependency inversion principle injection


Freek Lijten:
SOLID - The D is for Dependency Inversion Principle
Jan 02, 2013 @ 10:25:46

Freek Lijten has posted the last article in his series looking at the SOLID development principles, this time looking at "D", the Dependency Inversion Principle.

The DIP deals with avoiding mixing different levels of abstraction in your code. In this article we will explore the last of these principles in depth. [...] I want to show you how depending on abstractions makes our lives easier in a larger example. Since we're going to be loading, updating and storing bikes a lot in our application I would like an Api for that. It would not be such a good idea to write the same queries or perform the same validation over and over.

He includes two examples - one a bit simplistic involving bike storage and another more complex that uses interfaces to define structure and object injection rather than passing data around. He also tries to help clear up some of the confusion that might happen around dependency inversion and dependency injection.

tagged: solid development principle dependency inversion introduction


The Dependency Inversion Principle
May 10, 2012 @ 08:52:19


While some central concepts in the realm of object-oriented design are generally harder to digest at first, such as separation of concerns and implementation switching, more intuitive and untangled paradigms on the other hand are simpler, like programming to interfaces. Unfortunately, the DIP’s formal definition is surrounded by a double-edged curse/blessing that often makes programmers gloss over it, as in many cases there’s an implicit assumption that the principle is nothing but a fancy expression for the aforementioned “programming to interfaces” commandment.


tagged: dependency inversion principle solid dip tutorial


Devis Lucato's Blog:
Select: Inversion of Control
Dec 14, 2011 @ 13:34:53




tagged: inversion control designpattern select implementation