Federico Cargnelutti

Category: Design Patterns

  • How to create a Data Container Component in React

    One pattern I’ve used quite a lot while working with React at the BBC and Discovery Channel is the Data Container pattern. It became popular in the last couple of years thanks to libraries like Redux and Komposer. The idea is simple. When you build UI components in React you feed data into them via…

  • Zend Framework DAL: DAOs and DataMappers

    A Data Access Layer (DAL) is the layer of your application that provides simplified access to data stored in persistent storage of some kind. For example, the DAL might return a reference to an object complete with its attributes instead of a row of fields from a database table. A Data Access Objects (DAO) is…

  • The Little Manual of API Design

    This manual gathers together the key insights into API design that were discovered through many years of software development on the Qt application development framework at Trolltech (now part of Nokia). When designing and implementing a library, you should also keep other factors in mind, such as efficiency and ease of implementation, in addition to…

  • Domain-Driven Design: Sample Application

    Last updated: 15 Feb, 2010 Part 1: Domain-Driven Design and MVC Architectures Part 2: Domain-Driven Design: Data Access Strategies Part 3: Domain-Driven Design: The Repository Some of the Domain-driven design concepts explained above are applied in this sample application. Directory Structure app/ config/ controllers/ UserController.php domain/ entities/ User.php UserProfile.php repositories/ UserRepository.php views/ lib/ public/ The…

  • Domain-Driven Design: The Repository

    Part 2: Domain-Driven Design: Data Access Strategies The Ubiquitous Language The ubiquitous language is the foundation of Domain-driven design. The concept is simple, developers and domain experts share a common language that both understand. This language is set in business terminology, not technical terminology. This ubiquitous language allows the technical team become part of the…

  • Domain-Driven Design: Data Access Strategies

    Part 1: Domain-Driven Design and MVC Architectures The Domain Model Here are some of the features a Domain-driven design framework should support: A domain model that is independent and decoupled from the application. A reusable library that can be used in many different domain-specific applications. Dependency Injection in order to inject Repositories and Services into…

  • Domain-Driven Design and MVC Architectures

    According to Eric Evans, Domain-driven design (DDD) is not a technology or a methodology. It’s a different way of thinking about how to organize your applications and structure your code. This way of thinking complements very well the popular MVC architecture. The domain model provides a structural view of the system. Most of the time,…

  • Favour object composition over class inheritance

    What does “favour composition over inheritance” mean, and why is it a good thing to do? Object composition and inheritance are two techniques for reusing functionality in object-oriented systems. In general, object composition should be favoured over inheritance. It promotes smaller, more focused classes and smaller inheritance hierarchies. Troels Knak-Nielsen wrote: Class inheritance is a…

  • 10 concepts that every software engineer should know

    In this post, Alex Iskold discusses the top 10 concepts software engineers should know. A successful software engineer knows and uses design patterns, actively refactors code, writes unit tests and religiously seeks simplicity. Beyond the basic methods, there are concepts that good software engineers know about. These transcend programming languages and projects – they are…

  • The best code is very shy

    The best code is very shy. Like a four-year old hiding behind a mother’s skirt, code should not reveal too much of itself and should not be too nosy into others affairs. But you might find that your shy code grows up too fast, shedding its demure shyness in favor of wild promiscuity. When code…

  • Getters and setters create unnecessary coupling

    Every getter and setter in your code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters (also referred to as accessors, accessor methods, and properties) is a sign of a poorly designed set of classes. “Getters and setters should be avoided because they break the encapsulation OOP offers”, says…

  • Design Patterns Quick Reference

    Jason McDonald posted some quick reference diagrams for the Gang of Four design patterns on his blog. Each section has the name of the pattern, a quick description, and the class diagram for the pattern. Definitely a handy thing to have around. Design Patterns Quick Reference (PDF)

  • Working Effectively with Legacy Code

    Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts. In the book Working Effectively with Legacy Code,…

  • Dependency Injection and the Zend Framework

    A couple of months ago I wrote a Dependency Injection component for the Zend Framework. It’s a simple solution to a complex problem: removing hidden dependencies and injecting mocked objects. The component has evolved quite a bit since I first created it, and it’s now part of a bigger system, where objects are persistent, can…

  • Software Development AntiPatterns

    An AntiPattern is a pattern that tells how to go from a problem to a bad solution. For example: The Blob Procedural-style design leads to one object with a lion’s share of the responsibilities, while most other objects only hold data or execute simple processes. The solution includes refactoring the design to distribute responsibilities more…

  • Implementing the Delegation Pattern Using Reflection

    Times arise where a class (One) is supposed to do everything another class (Two) does and more. The preliminary temptation would be for class One to extend class Two , and thereby inheriting all of its functionality. However, there are times when this is the wrong thing to do, either because there isn’t a clear…

  • Registry Pattern, good or bad?

    Today I came across an interesting post written by Troels Knak-Nielsen. We all know that patterns are not perfect in all situations and the Registry pattern is no exception. Here is what Troels has to say about this:

  • Polymorphism

    The subject of polymorphism is probably the most important in OOP. Using classes and inheritance makes it easy to describe a real-life situation as opposed to just a collection of functions and data. They also make it much easier to grow projects by reusing code mainly via inheritance. Also, to write robust and extensible code,…