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

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/

Mathias Verraes:
Resolving Feature Envy in the Domain
August 12, 2014 @ 11:55:24

Mathias Verraes has a new post today about something he calls "feature envy" in the domain, related to this code smell (based on a definition from Martin Fowler).

Benjamin Eberlei did a really nice job of explaining refactoring the Feature Envy code smell on his blog. I wrote a comment because I felt the example could be taken one step further. You should read the original post. Below are Benjamin's code examples (for reference), followed by a repost of my comment.

The "smell" is defined as "a method that seems more interested in a class other than the one it's in". Mathias includes the code examples from the other post showing a datetime calculation and how it could be abstracted out to another class and method. He talks about the migration and how it relates to the "Whole Value" pattern and integrating some of the logic into a factory, generating a "reporting period" instance. He finishes the post with a brief look at an application of domain-driven design concepts to the problem, suggesting that the reporting be even more abstracted from the datetime data and using the "reporting period" object instead.

0 comments voice your opinion now!
feature envy whole value designpattern class object abstraction domaindriven

Link: http://verraes.net/2014/08/resolving-feature-envy-in-the-domain/

Mathias Verraes:
When to Use Static Methods
June 16, 2014 @ 10:20:52

Mathias Verraes has followed up his previous post about named constructors in PHP with a bit more clarification about when to use static methods (as he did in his "multiple constructor" examples previously).

Some of the reactions to my last blog post on Named Constructors in PHP, originate from the notion that static methods are inherently bad and should never be used. This is rather overgeneralized. Static methods are nothing more than namespaced global functions. Namespacing, I think we can all agree on, is great. As for global functions: We use those all the time. The native functions in PHP form our basic building blocks.

He talks about the main problem with their use, the shared global state, and compares it to a more stateful service. His solution is to either move to a normal object state (that allows for internal tracking) or think more about abstractions and how they relate.

0 comments voice your opinion now!
static methods opinion object stateless abstraction

Link: http://verraes.net/2014/06/when-to-use-static-methods-in-php/

Wojciech Sznapka:
Immutable value objects in PHP
May 16, 2014 @ 09:04:27

Wojciech Sznapka has a quick post to his site today looking at a possible implementation of Value Objects (immutable objects) in PHP applications.

Value objects are one of building blocks in Domain Driven Design. They represents a value and does not have an identity. That said, two value objects are equal if their values are equal. Other important feature is that Value Objects are immutable, i.e. they can not be modified after creation. [...] This post isn't about obvious advantages of representing domain logic with support of Value Object. As well, we wouldn't elaborate here about pros and cons of immutable objects. I'd rather would like to show an attempt to change Value Object.

His change method isn't so much a "change" as a "duplicate with new values" process. In his example he creates a EmailValueObject with "host" and "mailbox" properties. This object has a "changemailbox" method that seems to update the "mailbox" property, but in actuality clones the current object with a new "mailbox" value in the constructor.

0 comments voice your opinion now!
value object immutable clone change property

Link: http://blog.sznapka.pl/immutable-value-objects-in-php/

VG Tech:
Comparing Your Privates in PHP
March 19, 2014 @ 09:56:33

In a new post to their blog, the VG Tech folks talk about "comparing your privates" with a "hidden" feature of PHP. Don't worry, they're referring to private class properties on object instances here...

I was going to compare several private properties between to objects and started making a piece of code to perform the actual comparison using getters for the properties. I felt the approach sucked, and started looking into alternatives way to do this.

He shares what the current PHP documentation shares about comparing objects, but neither of them take private properties into account. He remembers, however, that object visibility is at the class level not instance level, allowing two object instances of the same class to have access to all properties of the other, regardless of exposure level. He includes a code snippet showing how to use this to compare those private properties.

0 comments voice your opinion now!
private comparison object instance class

Link: http://tech.vg.no/2014/03/14/comparing-your-privates-in-php/

Nikita Popov:
Methods on primitive types in PHP
March 17, 2014 @ 12:11:22

In his latest post Nikita Popov highlights one of the topics from this post, primitive types as objects, and some alternative options.

A few days ago Anthony Ferrara wrote down some thoughts on the future of PHP. I concur with most of his opinions, but not all of them. In this post I'll focus on one particular aspect: Turning primitive types like strings or arrays into "pseudo-objects" by allowing to perform method calls on them. [...] Note that this isn't far off dreaming, but something that already exists right now. The scalar objects PHP extension allows you to define methods for the primitive PHP types. The introduction of method-call support for primitive types comes with a number of advantages.

Among the advantages he lists:

  • The opportunity for a cleaner API (instead of the current, sometimes oddly named functions)
  • Improved readability
  • Polymorphism through a "cleaning up" of shared methods
  • Loose Typing

He also looks at possible ways that other primitive types could be handled (like "null" or "float") and some of the problems that could come up when passing objects around. Since the values could be an object or scalar, how would you know the difference. He finishes off the post with a look at the current state of things, including that there's not much resistance just that there hasn't been a good API defined to make it work.

0 comments voice your opinion now!
method primitive type object example problems

Link: http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html

Ross Tuck:
Persisting Value Objects in Doctrine
March 03, 2014 @ 10:11:29

Ross Tuck has submitted a new article he's posted about persisting value objects in the popular PHP database storage and object mapping library, Doctrine. Value objects are immutable objects that " follow value semantics rather than reference semantics".

I've been using more and more Value Objects in my applications over the last year, primarily with Doctrine ORM. Value Objects are an extremely powerful technique and I've been impressed with how much they can clean up a codebase. One of the main questions I've had when starting with Value Objects is how to persist them with Doctrine. This post attempts to create a reference for all the different persistence techniques I've seen so far.

You'll need to be familiar with Value Objects and Doctrine before starting (it's not an "intro to Doctrine" article). His example sets up an "IPRange" and an "IPAddress" that are stored in a "Server" instance. He talks about mapping the value object to the database and the getter/setter to do the work. He also touches on DBAL types, working with multiple columns in the entity and the "promised land" of embeddables. He finishes off the post looking at collections of entities and some of the other options to what he's shown (including serialization).

0 comments voice your opinion now!
doctrine valueobject value object database entity dbal embeddables

Link: http://rosstuck.com/persisting-value-objects-in-doctrine/

Derick Rethans:
DateTimeImmutable
February 26, 2014 @ 10:26:45

In his latest post Derick Rethans (knower of all things date and time) talks about the DateTimeImmutable functionality. It has been added into the PHP 5.5 releases and provides the same DateTime functionality but removes the ability for modification (mutability).

The first time that my improved DateTime support made its way into PHP was officially in PHP 5.1, although the more advanced features such as the DateTime class only made it appearance in PHP 5.2. Since its introduction the DateTime class implementation suffered from one design mistake - arguably not something that even an RFC would have highlighted. [...] This mutability property that all modifying methods of the DateTime class have is highly annoying, and something that I would now rather remove. But of course we cannot as that would break backwards compatibility. So in PHP 5.5, after a few stumbles, I finally managed to rectify this.

He includes some code examples showing the current DateTime object's mutability (via the "modify" function) and the new immutable handling. This new handling doesn't update the current object but instead returns the modified object, leaving the initial one intact. You can find out more about this new object in the PHP manual.

0 comments voice your opinion now!
datetime datetimeimmutable mutability return object php55

Link: http://derickrethans.nl/immutable-datetime.html

QaFoo:
Learn OOD - to unlearn it again
February 11, 2014 @ 12:52:10

In this latest post to the QaFoo blog Tobias Schlitt recommends learning proper object-oriented design first before trying to worry about the interactions between the objects.

One topic we regularly teach in workshops for our customers is object oriented design (ODD), i.e. the art of crafting classes/interfaces in a way that the result is an easy-to-understand, maintainable and flexible code base. With the agile focus on shipping working software, some might consider the skill of OOD less important. One popular argument is that quick reaction to change is more important than designing objects and their interaction carefully. I personally look at it the exact other way around. This blog post summarizes why you need to learn OOD first, in order to avoid it to some degree again.

He's broken up the rest of the post into a few different topics reinforcing this idea:

  • Learning OOD the classical way
  • OOD in fast pace and agile
  • Refactoring is the key
  • Learning OOD to unlearn it

Finally, he makes the recommendation that all developers should learn about effective refactoring and automated testing to help create well-structured OOP applications.

0 comments voice your opinion now!
learn ood oop objectorienteddesign design object learn

Link: http://qafoo.com/blog/064_learn_ood_to_unlearn_it.html

Evert Pot:
jCard is now a thing
January 21, 2014 @ 11:04:18

In his most recent post Evert Pot talks about jCard, a JSON-based format that was recently approved to serve up VCard personal information data in an easier-to-parse format.

I'm a big fan of this format. vCards have been around since 1995, and even though we've had a pretty significant update in 2011 in the form of vCard 4.0, the format is still complicated to parse, has a number of problems that go all the way back to the early days. [...] The biggest problem with vCards, is that upon a first glance, the format seems extremely easy to parse and generate with just a couple of string manipulation functions. When you dig deeper into the specifications though, you'll notice that it's actually really complex and hosts a ton of edge cases.

He includes an example of how to generate the jCard format using the Sabre/Object and the resulting output, both in the traditional vCard format and the new jCard structure.

0 comments voice your opinion now!
vcard jcard json format sabre object parse output

Link: http://evertpot.com/jcard-completed


Community Events





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


project bugfix introduction api series podcast threedevsandamaybe application interview community framework list code developer release configure language wordpress library laravel

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