Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

(Originally asked on StackOverflow - http://stackoverflow.com/questions/14896121/what-is-a-practical-level-of-abstraction-in-a-web-application)

I still consider myself a newcomer to OO programming, especially in php, so forgive me if I have missed some fundamental principle!

Say I have an intranet application with a staff object with properties and methods unique to being a member of staff:

class staff {
    ...
    private $job_title;
    private $start_date;
    etc...
}

In the quest to keep the maintainable parts of my code in one place, make my data model more intelligent and make my code less tightly-coupled, is it reasonable to abstract each object property to another level?

For example, I expect each property to have a value, but to complicate matters, I'm also interested in what label and description to use when referring to it in human-readable applications. More of interest is which type it is, as well as the capability of the object to validate itself, if its member properties can validate themselves also. It seems then, that properties of the majority of objects have a lot in common. So, the $start_date property might actually be an object in itself:

abstract class property {
    public $value = NULL;
    protected $label; // A simple label which can be used on user forms, reports, etc.
    protected $description; // Some detail to describe what this property is used for
    protected $type; // Helps choose the right HTML form control and validate user input
    protected $regex; // Regular expression to prompt user entry and validate return value
    protected $unique = FALSE; // If TRUE, check for duplicates in the persistence layer
    protected $default_value; // Prompt the user when entering new values
    protected $HTML_form_element; // Which form element suits this field best?
    etc....
}

class start_date extends property {
    ...
    public function __construct(){
        ...
        $this->label = 'Start date'; // Might be an i18n entry
        $this->description = 'Enter the date on which the contract starts for this staff member'; // Might be an i18n entry
        $this->type = 'VARCHAR(512)'; // Better to use persistence layer's requirements?
        $this->regex = '/^([0-9]{1,2})[/.-]([0-9]{1,2})[/.-]([0-9]{2,4})$/'; // UK date
        $this->default_value = date('Y-m-d'); // Depends on the business policy of the company
        $this->HTML_form_element= 'datepicker'; // Chooses the correct HTML element when building forms automatically
        ...
    }
    etc...
}

class staff {
    ...
    public function __construct(){
        ...
        $start_date = new start_date();
        ...
    }
    etc...
}

In previous applications, these related things have lived in different places; random global variables, commented code, decorator objects, a config file, embeded in HTML, a database table, a scrap of paper. It makes sense to bring all an objects properties together in one place, but is this the right way?

share|improve this question

closed as not constructive by Jim G., MichaelT, Glenn Nelson, Martijn Pieters, gnat Feb 18 '13 at 3:48

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

1 Answer

The data you are describing is meta data. Many languages have clean ways to store this information, such as annotations. The PHP team as rejected native annotations time and time again, but Symfony2 and Doctrine2 have a home-grown implementation using doc-block comments. This is far from the ideal solution, but it's the best work around we have at the moment. This is the same way annotations were created in Java before native annotations were implemented by Sun in Java 5.

I'm not sure if the Symfony/Doctrine solution is available as a stand alone component or not. I think Symfony relies on the doctrine-common library to parse annotations.

Either way, check out Symfony2 Form Vaidation

// Acme/TaskBundle/Entity/Task.php
use Symfony\Component\Validator\Constraints as Assert;

class Task
{
    /**
     * @Assert\NotBlank()
     */
    public $task;

    /**
     * @Assert\NotBlank()
     * @Assert\Type("\DateTime")
     */
    protected $dueDate;
}

The information you're trying to describe with a has-a relationship above is cleanly described here without muddying up the code. Internally, these comments are parsed and cached in pure PHP so they can be looked up at run-time.

share|improve this answer
1  
A bit off-topic, but can you elaborate on why the PHP team rejected annotations? –  Earlz Feb 15 '13 at 15:53
    
From what I can tell, it's mostly been that they don't accept the purposed implementation. I think syntax has been the biggest factor. –  Craige Feb 15 '13 at 15:58
    
Found this a while back: interfacelab.com/metadataattributes-in-php –  Bendos Feb 15 '13 at 16:19
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.