accessing the behaviors and attributes of a sibling
Delirium tremens
of the other child class. If I create a child object, can I access the
behaviors and attributes of the other child object?
I have 3 classes (FormChecker, FormSmall and FormBig). In all, I have
the formBuild behavior. In all, I have the formfields attribute. I
need to use all formBuild behaviors to access one formfields
attribute. Is that possible? How?
I want FormSmall to extend FormChecker and FormBig to extend
FormChecker. I need to access a method in FormSmall and a method in
FormBig. I need to access one formfields. Is that possible? How?
I mean, if I create two objects, one for FormSmall and one for
FormBig, they will not share the attributes or will they?
Jerry Stuckle
> If a parent class has two child classes, one child class is a sibling
> of the other child class. If I create a child object, can I access the
> behaviors and attributes of the other child object?
>
No. When you create a child object, you are creating only that child
and the parent.
> I have 3 classes (FormChecker, FormSmall and FormBig). In all, I have
> the formBuild behavior. In all, I have the formfields attribute. I
> need to use all formBuild behaviors to access one formfields
> attribute. Is that possible? How?
>
> I want FormSmall to extend FormChecker and FormBig to extend
> FormChecker. I need to access a method in FormSmall and a method in
> FormBig. I need to access one formfields. Is that possible? How?
>
OK, it sounds like formfields should be a member of the FormChecker
class and not FormSmall or FormBig. Then derive FormBig and FormSmall
from FormChecker.
> I mean, if I create two objects, one for FormSmall and one for
> FormBig, they will not share the attributes or will they?
FormSmall and FormBig will have their own attributes, as will
FormChecker. You can define formfields in FormChecker as a static
field, in which cases, all instances of FormChecker will share that one
attribute.
However, my first question is about your inheritance hierarchy. You
should have an "is-a" relationship between the child and the parent.
"Is-a" FormSmall a more specialized type of FormChecker? To me, it
sounds like FormChecker is more of a method than an object ("Check"
being a verb).
Maybe what you really need is a generic "Form" class, with a "check" method.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Delirium tremens
> Delirium tremens wrote:
> > If a parent class has two child classes, one child class is a sibling
> > of the other child class. If I create a child object, can I access the
> > behaviors and attributes of the other child object?
>
> No. When you create a child object, you are creating only that child
> and the parent.
>
> > I have 3 classes (FormChecker, FormSmall and FormBig). In all, I have
> > the formBuild behavior. In all, I have the formfields attribute. I
> > need to use all formBuild behaviors to access one formfields
> > attribute. Is that possible? How?
>
> > I want FormSmall to extend FormChecker and FormBig to extend
> > FormChecker. I need to access a method in FormSmall and a method in
> > FormBig. I need to access one formfields. Is that possible? How?
>
> OK, it sounds like formfields should be a member of the FormChecker
> class and not FormSmall or FormBig. Then derive FormBig and FormSmall
> from FormChecker.
>
> > I mean, if I create two objects, one for FormSmall and one for
> > FormBig, they will not share the attributes or will they?
>
> FormSmall and FormBig will have their own attributes, as will
> FormChecker. You can define formfields in FormChecker as a static
> field, in which cases, all instances of FormChecker will share that one
> attribute.
What if I need FormSmall, FormBig and FormChecker to share an
attribute?
>
> However, my first question is about your inheritance hierarchy. You
> should have an "is-a" relationship between the child and the parent.
> "Is-a" FormSmall a more specialized type of FormChecker? To me, it
> sounds like FormChecker is more of a method than an object ("Check"
> being a verb).
>
> Maybe what you really need is a generic "Form" class, with a "check" method.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
Jerry Stuckle
As I said - have a static attribute in the parent class - all objects of
that class will share the same attribute.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Delirium tremens
> ==================
I heard static attributes make modular code like procedural code. Is
there an alternative solution?
Delirium tremens
> ==================
"Static members make object oriented much like old procedural
programming; without creating instances, you can directly call any
function, like the old days. That's why we use static method with
caution. Excessive static methods make no use at all." - Object
Oriented Programming with PHP 5
Delirium tremens
> ==================
ooops! I quoted about static methods, not static attributes...
Curtis
> programming; without creating instances, you can directly call any
> function, like the old days. That's why we use static method with
> caution. Excessive static methods make no use at all." - Object
> Oriented Programming with PHP 5
There's no reason you can't instantiate a class *and* make use of
static members. Here's an example:
<?php
// parent class
class Foo {
protected static $static;
function __construct($set = '') {
if ($set)
$this->set($set);
$this->get();
}
public function set($data) {
self::$static = $data;
}
public function get() {
echo 'Called by `' . get_class($this) . '\': '
. self::$static . "\n";
}
}
// child classes
class Bar extends Foo { }
class Baz extends Foo { }
$bar = new Bar('BAR');
$baz = new Baz;
echo "\n";
$baz->set('BAZ'); // static var now holds 'BAZ'
$bar->get();
$baz->get();
?>
Using getters and setters properly, you can avoid locking yourself
down to particular implementations in your classes. Despite using
the static, it doesn't hinder usage of the objects.
--
Curtis
$email = str_replace('sig.invalid', 'gmail.com', $from);
Jerry Stuckle
> there an alternative solution?
I don't know where you got that idea.
No, there isn't any other way to share an attribute like that. But as
I also said before - it looks like your design has other problems. They
aren't helping matters any.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Jerry Stuckle
> programming; without creating instances, you can directly call any
> function, like the old days. That's why we use static method with
> caution. Excessive static methods make no use at all." - Object
> Oriented Programming with PHP 5
That's one persons opinion. It is not shared by a large number of OO
programmers (including experts like Booch, Rumbaugh and the like).
Additionally he's also talking about methods, not attributes.
And exactly what is "excessive"?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================