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. Only valid way to create Value Object is to pass all required informations to constructor (and should be validated somewhere there). No setter methods should take place.

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, keeping it still immutable and using one of most bizarre, in my opinion, feature of PHP language, which is accessing private fields from outside an object.

Often time you would like to alter Value Object, by creating new one based on current (which is only valid way). Altering logic conceptually belongs to Value Object class, so should be located there. In such method, you clone current instance, set new information to given field and return the copy. And this is were accessing private fields for same class makes sense. You can do that without having additional setters which will break the design.

As illustrated above, all Value Object features are in place. This example is of course trivial, but you can imagine a lot more complicated VO’s, like values shared between bounded contexts.

Już za kilka miesięcy (26-28 września) 5. edycja PHPCon Poland. Po kilku latach z małej konferencji dla miłośników PHP urośliśmy do największej konferencji poświęconej PHP w tej części Europy. W minionym roku było nas już ponad 420 uczestników.

W tym roku PHPCon Poland również odbędzie się na południu Polski, tj. w hotelu Orle Gniazdko w Szczyrku. Dla niektórych może daleko, ale naprawdę warto nie tylko ze względu na konferencję ale również na miejsce.

Zanim rejestracja uczestników zostanie otwarta zachęcam do zgłaszania własnych prelekcji. Organizatorzy czekają do 20 maja (max. 31 maja) na zgłoszenia. Zgłoszeń jest już sporo, ale w tym roku zrządzeniem losu Polacy są w mniejszości. Do dzieła! A jeśli Ty nie masz czasu namów znajomych na zgłoszenie.

Wystarczy wypełnić prosty formularz podając tytuł, abstrakt i link do prezentacji (na tym etapie może to być wersja robocza, abyśmy mieli o czym rozmawiać).

A już w czerwcu co roczna sonda agendowa, po której Prelegenci dowiedzą się o statusie swoich zgłoszeń i zacznie się układanie agendy.

Wpis o tym w jaki sposób dodać, edytować, usunąć, pobrać oraz wylistować wydarzenia znajdujące się w kalendarzu google przy pomocy biblioteki z Zend Framework 1 o nazwie Zend_Gdata. Połączenie z kontem: Dodanie nowego wydarzenia: Edycja zdarzenia: Usunięcie...

Some time ago I rediscovered PHP SPL library. After reading Joshua Thijssen’s Mastering the SPL Library I found out that sometimes I was reinventing the wheel in my code, sorry (employers and customers). Iterators are one of the SPL library components. To add more spice to code I’ll show some kind of JavaScript magic using closures.

Simplest and best iterator definition:

Iterators are PHP’s way of dealing with abstracting away the traversal logic from the business logic. This, in one sentence, sums up what an iterator is. [A. Thijssen : Mastering…, p. 68]

My goal for today is to show you how to use IteratorAggregate with CallbackFilterIterators to filter out files not meeting our requirements. Feel free to use this class in your own projects.

Lately I see perilous situation in software development area. There are plenty of good devs so much bounded to tools. By tools, I mean mostly frameworks. I would like to elaborate a bit about that, but those are my personal opinions and they aren’t here to offend anyone.

First of all, we all need to admit, that quality of modern MVC framework raised a lot, comparing with state of things few years ago. Speaking about PHP – at the time, when I attracted my attention to this language, there were pure wilderness. We did not have any strong framework (unlike Ruby On Rails, which were sine qua non choice for Ruby web development). That caused multiple projects development, some of them are dead now (or should be), some hasn’t got good market adaptation and some of them are industry leaders at the moment (Symfony and Zend).

On the other hand, there’s huge temptation to write own frameworks, ignoring the great work of community. That has some advantages, in case you know exactly what you’re doing. Only one good reason for me is performance concerns. But still, doing everything by hand proves lack of understanding of tools and leads to giant problems with system maintenance. For me, it’s hard to imagine how one could create a complex system without usage of good framework. What’s more, its economically unreasonable to recreate the code, that already exists.

Alright, it’s clear –  applications which will serve their purpose are way easier to be created with modern framework. The choice isn’t easy (as well as choice of language), but if you ask me, I’ll say: pick the one you feel the most comfortable with and which is built on top of best design patterns. A framework won’t do the job by its own, though. And this is the point I’d like to make: don’t be bound to the framework. The best quote to reflect this point of view is:

The architecture of an accounting app should scream “accounting” not Spring & Hibernate. Robert C. Martin via https://twitter.com/unclebobmartin/status/118365858581069824

By decoupling from framework (see Jakub Zalas slides) you’ll benefit in multiple ways: your code will be loosely coupled, easier to understand, readable, testable and most important: it will be robust. If for some reason, you’ll have to change framework (because yours isn’t supported any more and super 3rd edition of famous framework comes to general availability), you’ll spend considerably less amount of time to migrate to new libraries.

A thing to remember is, that good software design practices, such as design patterns or SOLID principles, exists for years now. They are applied in all software languages and you’ll find similar concepts both in Java Spring and PHP Symfony. Frameworks, on the other hand comes and goes. In 3 years from now, there won’t be Symfony2 or Zend Framework2, but your code will be still alive and need to be maintained. It’s your choice, if it be completely dependent on framework or if it will rely on proven patterns.

I strongly encourage to read and apply philosophy of Domain Driven Design. It’s better to focus on a core domain and reflect business needs by modelling them with code. Once you’ll be focused on domain, you’ll start to see that framework is only implementation detail and you’ll stop calling yourself Symfony Developer or Zend Developer, but rather Software Developer.

Tworząc nawet małą aplikację internetową musimy zadbać o „przyjazne” linki. Zwiększają one wygodę użytkownika, jak i mają istotny wpływ na SEO. Gdy piszemy aplikację w oparciu o jeden z popularnych frameworków problemu nie ma, dostarczają one komponenty do tworzenia ładnych adresów, ale co w sytuacji, gdy tworzymy bez ich wsparcia? Jednym z rozwiązań jest napisanie […]

Załóżmy następującą sytuację: tworzymy w Zend Framework formularz, który wśród swoich pól będzie zawierał pole typu select. Pole te ma służyć do wyboru np. języka. Kod html, który ma powstać będzie wyglądał tak: Jak widać nie ma tutaj nic specjalnego. Musimy tylko zadbać, aby użytkownik dokonał wyboru jakiegoś języka. Kod formularza zawierający takie pole w […]