By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,317 Members | 1,314 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,317 IT Pros & Developers. It's quick & easy.

Encapsulation vs. __set and __get

P: n/a
I'm writing a web application that requires meta data in some objects.
I'm trying to make to API as clean as possible. Would it be better to
have something like this:

class Mama {
public $meta;
function __construct(){
$this->meta = new Meta(array of data);
}
}

class Meta {
private $_values;
private $_modified;
function __contruct($array){
$this->_values = $array;
$this->_modified = FALSE;
}
function __set($name,$value){
$this->_modified = TRUE;
$this->_values[$name] = $value;
}
function __get ($name){
return $this->_values[$name];
}

}

-or-

class Mama {
public $_meta = array('name' => 'value';
function getMeta($name){
return $this->_meta[$name];
}
function setMeta($name,$value){
$this->_meta[$name] = $value;
}
function delMeta($name){
unset($this->_meta[$name])
}

}

I haven't done much OOP before, so I don't know what is "standard
practice." The project is for a small school newspaper, so it's more of
a programming excercise for me. What is more OOP correct?

-Pingveno
Jul 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Pingveno wrote:
I haven't done much OOP before, so I don't know what is "standard
practice." The project is for a small school newspaper, so it's more
of a programming excercise for me. What is more OOP correct?


Using __get and __set methods, only means that you want to use overloading
to enable calls like:

$mama = new Mama;
$mama->meta->foo = 'bar';
print $mama->meta->foo;

In this example you can see the first problem: because overloading is only
supported in the Meta class, you are forced to use the multiple object
operator syntax to access the $_values property of the Meta class. This
causes your code to be less readable and the usage of your class less
obvious.

To improve this, you could move overloading from the Meta class to the Mama
class. The overall design of the Mama class determines whether this is a
good choice and the way you want to use it determines if you should use
overloading at all.

As an alternative, you could design the Meta class as an interface, with an
implementation in the Mama class and clearly defined methods:

interface Meta {
public function setMeta($name, $value);
public function getMeta($name);
}

class Mama implements Meta {
private $_values;
function __construct($array){
$this->_values = $array;
}

function getMeta($name) {
return $this->_values[$name];
}

function setMeta($name, $value) {
$this->_values[$name] = $value;
}
//.... other methods specific to the Mama class
}
JW

Jul 17 '05 #2

P: n/a
"Pingveno" <pi**************@comcast.antispam.net> wrote in message
news:LY********************@comcast.com...
I haven't done much OOP before, so I don't know what is "standard
practice." The project is for a small school newspaper, so it's more of
a programming excercise for me. What is more OOP correct?


The standard practice, I dare say, is not to make a distinction between
"data" and "meta data," as that adds to the complexity of the interface. The
caller doesn't need to know the nature of what it is accessing. Both should
be present plainly as properties. Whatever differences between the two type
should be handled within the class.
Jul 17 '05 #3

P: n/a
"Henk Verhoeven" <ne***@phppeanutsREMOVE-THIS.org> wrote in message
news:d3**********@news2.zwoll1.ov.home.nl...
Actually i do not see any meta data here (IMHO meta data is data about
data). Pingveno's second example i would call an associative multi value
property named 'meta' and the only thing meta about this property would
be its name.


Personally I dislike the term "meta data." Data is what a computer deals
with. Any piece of data could be about another piece. The author of an
article, for example, could be considered meta data of the article.

In any event, just because something is meta data doesn't mean you have to
model it that way.
Jul 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.