Posts tagged with design patterns
In a new article on his blog Frank De Jonge demonstrates a lesser known feature/bug of PHP.
When two objects are of the same type, they can access the private properties of the other. This might seem like a bug, but it's actually a very valuable feature. For instance, it allows you to perform very efficient equality checks without the need to publicly expose your internals.http://blog.frankdejonge.nl/pipelines-immutability-and-privates/
Ross Tuck does not blog often, but when he does you probably are going to learn something useful. In his latest post he shares some techniques regarding exceptions.
Over the last couple years, I’ve started putting my Exception messages inside static methods on custom exception classes. This is hardly a new trick, Doctrine’s been doing it for the better part of a decade. Still, many folks are surprised by it, so this article explains the how and why.http://rosstuck.com/formatting-exception-messages/
Join thousands of developers
Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.
No spam. Unsubscribe anytime. You can also follow me on X.
A really great talk by Sandi Metz in which she refactors a nasty block of conditional code to a few small, understandable objects.
https://www.youtube.com/watch?v=8bZh5LMaSmE
Watch it on Vimeo.In object-oriented development, we are all familiar with design patterns such as the Strategy pattern and Decorator pattern, and design principles such as SOLID.
The functional programming community has design patterns and principles as well.This talk will provide an overview of some of these, and present some demonstrations of FP design in practice.
If you're going to read one article on ActiveRecord vs Data Mapper let it be this one by Matthew Machuga.
The next time you come across the ActiveRecord vs. Data Mapper argument, or ones like it, be critical of what is being said. If it impacts your work in some way, do some research to find out if what is being said is true or if it has been something lost in translation. Don't feel bad for using a pattern that has spread across multiple languages and ecosystems successfully, and is probably the reason we have most of the web frameworks we do today. While the ActiveRecord existed well before Rails, it was Rails that gave it a beautiful API and made other frameworks like CodeIgniter, Laravel, .NET, Fuel, Django, etc want to have something comparable.http://matthewmachuga.com/blog/2015/activerecord-and-the-beauty-lost-in-translation.htmlIf you use Eloquent, ActiveRecord for Rails, or any other AR ORM, make sure you know that you are not alone. You are in good company of many, many developers who use it successfully day-to-day. However, if one day you choose to use a Data Mapper implementation or something else, then you will still be in good company, and still deserve respect regardless of which side of the fence you fall.
When I first learned to program, I made many objects that were mutable. I made lots of getters and lots of setters. I could create objects using a constructor and mutate and morph the heck out of that object in all kinds of ways. Unfortunately, this led to many problems. My code was harder to test, it was harder to reason about, and my classes became chock full of checks to ensure that it was in a consistent state anytime anything changed.http://blog.joefallon.net/2015/08/immutable-objects-in-php/...
Now, I favor creating immutable objects.
The post clearly explains the benefits of using immutable objects and a nice example.
One of the really great things about ORM’s that implement the Active Recordpattern like Eloquent is, they are really easy and really intuitive to use.http://culttt.com/2014/07/07/doctrine-2-different-eloquent/With Active Record, you basically just have an object that you can manipulate and then save. Calling
save()on the object updates the database, and all of the magic persistence happens behind the scenes.Having the business logic of the object and the persistence logic of the database tied together definitely makes working with an Active Record ORM easier to pick up.
In this tutorial I want to explore exactly how Doctrine 2, an ORM that implements the Data Mapper pattern, is different to Eloquent.
There are many ways to modify the behavior of existing code with actually changing the core logic. Some patterns you might be familiar with are the decorator pattern or the observer pattern. Both allow you to take another object and modify the behavior by wrapping your modifications around the original code. One pattern you might not be familiar with though, is the interceptor pattern.http://www.edzynda.com/aspect-oriented-php-and-the-interceptor-pattern/The interceptor pattern is a core concept of what is called aspect oriented programming (AOP). AOP aims to improve the modularity of your code by allowing you to separate cross-cutting concerns from the rest of your code.
PHP-DI is an easy to integrate IoC container that you can use in legacy projects or in apps without a framework.
I regularly have to use Zend Framework 1 for some legacy apps. If you're used to having an IoC container to inject dependencies then not having one is a big pain. Here's a guide on how to integrate it in ZF1:
http://php-di.org/doc/frameworks/zf1.html
A repository is a collection, a collection that holds entities and which can filter and return entities back based on the needs of your application. How it actually holds those entities is an implementation detail.http://shawnmc.cool/the-repository-pattern
A clear and concise explanation of the repository pattern.
I believe that the true value of what Eric Evans wrote years ago lies in the fact that virtually anybody can use some of the things he proposed. They don’t require any special tools, money, approval or reorganization. Those are simple things that you can start doing from next Monday (or tomorrow).http://weronikalabaj.com/ddd-ultra-lite/