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

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

Mathias Verraes:
Value Objects and User Interfaces
November 18, 2013 @ 11:35:07

Mathias Verraes has a new post today with a response to an email he received about some comments on a recent Elephant in the Room podcast about Value Object usage. The question asks about usage of Value Objects, specifically when it comes to things like country information.

There's nothing intrinsically wrong with modeling countries as entities and storing them in the database. But in most cases, that overcomplicating things. Countries don't change often. When a country's name changes, it is in fact, for all practical purposes, a new country. If a country one day does not exist anymore, you can't simply change all addresses, because possibly the country was split into two countries. Whenever you have this kind of friction, there's usually some missing concept screaming to be discovered.

He talks some about the concepts around the "country" data and some of the functional concerns around it (duplicate checking, validation of existence, etc). He takes the concept and breaks it out into two different concepts - the actual Value Object of a single country and an "AvailableCountries" set (and "AvailableCountryRepository").

0 comments voice your opinion now!
value object country example registry set

Link: http://verraes.net/2013/11/value-objects-and-user-interfaces/

David Adams:
Is ORM abstraction a pipe dream?
October 23, 2013 @ 09:59:21

David Adams has published a recent post that wonders if ORM abstraction is a "pipe dream" when it comes to abstraction. ORM stands for "object relational mapper" and is commonly used as a layer between the application and a dta source to work with the data as objects, not directly with it. He instead investigates replacing the ORM layer with multiple instances of repository pattern-structured code to abstract thing even more.

I was recently introduced to the repository pattern, a type of abstraction and organizational technique. The idea being, create a repository for each of your models to retrieve and persist to and from. A supposed benefit of the repository pattern is the ability to abstract your ORM and create different implementations for Eloquent, Doctrine, Propel, etc. This abstraction intrigued me. I set off to put this idea into practice and see what it took. Here are my findings.

He looks into how Doctrine handles its entities and tries to mimic some of the logic, including the calls to "save" and "flush". He also looks at how to handle a few other common ORM-ish topics like relationships, validation and observers. Unfortunately, he hit a wall with his solution and wasn't able to figure out a good Repository-based solution.

0 comments voice your opinion now!
repository designpattern proofofconcept orm object mapper doctrine entity

Link: http://programmingarehard.com/2013/10/21/is-orm-abstraction-a-pipe-dream.html


Community Events





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


podcast interview refactor code laravel configure release community install wordpress developer list language opinion series framework introduction threedevsandamaybe testing unittest

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