When working within an MVC architecture, it's common to use a template library to populate the dynamic content of our views. There are dozens of such libraries available for PHP, but Twig is one of the standouts because of the ability to extend core features with custom implementations. In this article we'll explore how Twig templates can be extended using template inheritance, filters, and functions.

He starts first with some of the common limitations of templating frameworks (extension) and how Twig gets around this. He shows the use of the "extends" keyword and the "block"/"endblock" for splitting up the page into reusable chunks. He also shows how to use filters and functions in your Twig tags, allowing for more customized content and functionality for your output.

Multiple inheritance isn't allowed in PHP. [It's not] possible with PHP (in Java is not possible either), but today we can do something similar (is not the exactly the same) with Traits. Let me explain that: Instead of classes we can create Traits.

He includes a code example showing the creation of two traits, "Base1" and "Base2", that are implemented (via "use") and the calls to methods on each. He also points out the error condition and message that can come up when there's a conflict in the method names between two or more traits. This is relatively easy to solve with the mapping ability of the "use" statement (code example included for that too).

The popular belief is that reusing implementation, thus producing DRYer code, boils down to exploiting the benefits that Inheritance provides, right? Well, I wish it was that easy! [...] If you don't know what path to travel when it comes to reusing implementation, in this article I'll be doing a humble walk-through on the Inheritance/Composition/Delegation trio in an attempt to showcase, side by side, some of their most appealing virtues and clunky drawbacks.

He starts off with a look at Inheritance, showing with a small code sample showing the creation of an interface and a resulting PDO adapter class implementing it. He also shows the concept of composition, following the ideas of the Adapter pattern. In his Delegation example he shows how to implement the creation of the connection object as a part of the class' creation.

Inheritance offers a straightforward way to easily spawn a large number of objects that are semantically related to each other without having duplicate code. The concept is ridiculously simple - yet powerful: you first drop as much logic as possible within the boundaries of a base type (usually an abstract class, but it could be a concrete one), and then start deriving refined subtypes according to more specific requirements. [...] Not surprisingly, this repetitive encapsulation/derivation cycle lays down on the formalities of a design pattern known as Layer Supertype.

They describe the "supertype" as a replacement for an overly bloated domain-related model. Their example replaces a PostInterface/CommentInterface with a more generic "AbstractEntity" that handles some of the basics for you - getting/setting, checking a field, setting an ID and outputing the information to an array.

In our previous post about the multiple and nested traits, we read how nested and multiple traits can be used in a class. In such cases, there is a possibility of the same method name existing in the trait, and the class using the trait. Furthermore, the same method name might also be present in the parent class of the class using traits. It is important to understand how the precedence order works for such cases.

First they look at the precedence between classes and traits with the class always winning...unless the method is inherited from a parent class. They also mention the order when it comes to using the "insteadof" and "as" operators as a way to get around conflicts between traits.

Our first idea, and it was not that bad, Drupal does just the same, was to have a database table with the common fields, a field containing the type of item (it's either an event or a blog post) and a data field where we serialized the corresponding PHP object. This approach was ok until we had to filter or search LabLog items based on fields that were contained in the serialized data.

To resolve the issue they turned to multiple table inheritance, relating the LabLogItem to both a BlogPost and Event. They also show how it could be modeled with a single table, but opt for the multiple method. Included in the post is the Doctrine-based code showing how to create the parent entity for the LabLogItem and the two child entities for the blog post and event. There's also a brief snippet showing how to use them with the EntityManager.

In this article I will discuss traits, a new feature introduced in PHP 5.4 to overcome [issues where multiple inheritance is needed]. The concept of traits itself is nothing new to programming and is used in other languages like Scala and Perl. They allows us to horizontally reuse code across independent classes in different class hierarchies.

Included in the post is example code showing what the use of a trait looks like and a method for creating a Singleton that can spawn instances of two classes. Also included are examples of:

• using multiple traits at once,
• traits made up of traits,
• the importance of order,
• aliasing to avoid conflicts,
• reflection
• and a few other features that come along with their use.

In this article we're going to explore the idea of inheritance in object-oriented programming, and how inheritance works in PHP. With inheritance, your objects and classes can become much more powerful and flexible, and you can save a lot of time and effort with your coding.

They start with the basics of how inheritance works and then move right into creating child classes from a parent. Their example code makes a basic forum system (just example code, not fully functioning) with administrators, members and forum creation. They use this as a base to show the method overriding and exposure with "final". The finish it off with examples of two things that can promote good application structure - abstract classes an interfaces.

In this second and concluding segment, I'll look at some of Twig's other features, including such goodies as template inheritance, custom filters and caching. If you enjoyed the first part of this article, keep reading to find out more about what goes on under Twig's hood, and how you can add even more power and flexibility to your templates

He looks at template inheritance, parent blocks/child templates, data filtering, the tool's "compilation cache" and working with native plugins.

In fact I think that using inheritance all the time is a very big mistake and makes your code hard to maintain and more hard to integrate (the latter is a mistake for application codes and a fatal mistake for libraries). The main problem with inheritance is that if you use it for coupling two classes, then a very important property of the subclass is used up: it's superclass. It is taken, reserved, and it can not be used for anything else furthermore. If you want to connect your subclass to an other class using inheritance, you can't.

He recommends avoiding the typical uses of typical superclass/subclass inheritance unless what you're doing specifically requires it. Working with interfaces, abstract classes and good composition planning is a much better idea.