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

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/

Anthony Ferrara:
Beyond Object Oriented Programming
November 12, 2013 @ 11:56:36

Following up on his previous post talking about going "beyond inheritance" in object-oriented development in PHP, Anthony Ferrara has a new post extends the subject, focusing more on types of classes and how his thoughts would apply.

In the last post Beyond Inheritance, we talked about looking past "types" and reasoning about objects differently. The conclusion was that inheritance wasn't necessary for OOP, and often results in more problems than it solves. Well, let's go beyond that and explore more of what will come from treating objects as containers of behavior. Let's look at what this means for various kinds of classes.

He looks at five different class types and gives a brief summary of the concepts they represent - Representers, Doers, Plumbers, Translators and Makers. He then shifts over to investigating how this all applies to the SOLID development principles. He follows this pattern of thought through and looks at how it breaks things down into decomposable behaviors and, ultimately, functional programming/code structures (including the suggestions that creating ValueObjects is directly related).

0 comments voice your opinion now!
beyond oop types solid development functional valueobject

Link: http://blog.ircmaxell.com/2013/11/beyond-object-oriented-programming.html

DZone.com:
Practical PHP Refactoring Encapsulate Downcast (and Wrapping)
November 04, 2013 @ 12:44:06

On DZone.com Giorgio Sironi has posted a refactoring recommendation around the handling of the data and types in your PHP code. He suggests the move from just a simple variable to a Value Object (noting that it's not really needed in PHP, but can provide a "richer interface" to work with the data).

Statically typed languages sometimes encounter the problem of downcasting: the compiler is only able to guarantee a basic type, and the object contained instead is an instance of a richer subtype. [...] You'll never need to downcast objects: variables can contain handlers to objects or even scalars without compile-time checks. Casting with (ClassName) is not even supported by the language (while casting a non-object with (object) will give you a stdClass.)

He starts by talking about scalar values in PHP and a simple form of downcasting - using the casting notation included in the language. From there he moves into the conversion into Value Objects and some of the updates (like docblocks) that would come with their use. He outlines some steps towards the conversion and provides an example set of scripts showing the conversion process.

0 comments voice your opinion now!
refactor scalara value variable valueobject downcast

Link: http://css.dzone.com/articles/practical-php-refactoring-38

Nicolas Bérard-Nault's Blog:
The unknown value of Value Objects
March 31, 2011 @ 12:12:46

Nicolas Bérard-Nault has put together a new post looking at the role that Value Objects play in application development and, more specifically, how they fit in with domain driven design (DDD). He looks to explain the unknown value of Value Objects to developers that might not know how helpful they really can be.

One of the main rules of DDD is that value objects are immutable. This is often not as self-evident as it seems, as many programmers are not even aware of the state they leak and create. Sadly, state is often positively correlated with entropy. Hence, taking steps to contain and to limit state is one of the keys to taming complexity in an application.

He notes that even outside of DDD Value Objects can be quite useful. He gives an example of a "RationalNumber" class with methods for basic things like addition and subtraction. He shows the more traditional mutable version that most developers would start with and uses it in several examples to show its flaws. He finishes up the post with a look at the "more correct" immutable version of the class and a sample call that would result in the correct output of a simple matematical operation.

1 comment voice your opinion now!
valueobject domaindrivendesign mutable immutable


Bradley Holt's Blog:
Immutable Value Objects in PHP
October 01, 2010 @ 11:15:40

Bradley Holt has a new post to his blog about a subject he's recently been learning about, Domain-Driven Design, and how immutable value objects could be useful in PHP.

Yesterday I tweeted: Modern object-oriented programming languages need support for immutable Value Objects. #DDD The "DDD" in that tweet stands for Domain-Driven Design. There were several interesting responses to this tweet.

Responses to his tweet included comments from Matthew Weier O'Phinney, Ralph Schindler, Nicolas Berard-Nault and Giorgio Sironi. He notes that, while all of the suggestions are good, they're only half of the issue. They make it immutable when defined but not during execution. Currently PHP lacks this functionality, but something like this could be worked in with the concept of a "final" class.

0 comments voice your opinion now!
immutable object domaindrivendesign ddd valueobject


PHPFreaks.com:
Design Patterns - Strategy/Bridge, Value Object, Singleton (Registry)
October 10, 2008 @ 09:33:10

Following up on their introduction to design patterns, the PHP Freaks have posted tutorials covering three of the more popular patterns - strategy/bridge, value object and singleton.

  • Strategy and Bridge - The Strategy and Bridge patterns provide solutions to apply polymorphism in more flexible way than you can accomplish with only inheritance.
  • Value Object - The Value Object pattern has, just like the Singleton, to do with referencing and instances. In a way, the Value Object is the opposite of the Singleton: it's goal is to ensure NOT to use the same instance, under certain conditions.
  • Singleton and Singleton Registry - The Singleton pattern ensures that you are always dealing with the same, single instance, wherever in your application. The Registry pattern usually utilizes the Singleton pattern (hence "Singleton Registry") to make the same 'globalness' apply to objects who's classes weren't necessarily designed to

Keep checking back to their tutorials section for more design pattern tutorials.

0 comments voice your opinion now!
design pattern singleton registry valueobject strategy bridge


Knut Urdalen's Blog:
ORM the manual way
August 29, 2007 @ 07:57:00

Knut Urdalen, on seeing some of the recent discussion on why the ActiveRecord pattern sucks and talks about why, when presented with a the need for a database layer, he usually goes back to his own familiar Singleton-based style.

I normally use a simple solution using the Singleton pattern for managing the database connection, the Value Object pattern for all business objects and the Data Mapper pattern to manage the mapping between business objects and the database schema. It's as simple as that '" handcrafted and no magic going on.

The post also includes his code for an example of a database connection - the creation of the Singleton interface class, making the Value Objects and customizing one for the type of "Product".

0 comments voice your opinion now!
orm database layer singleton valueobject example designpattern orm database layer singleton valueobject example designpattern



Community Events





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


symfony framework conference podcast deployment introduction laravel development api interview tips language series code community release developer list threedevsandamaybe zendserver

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