[SOLVED] class functions

[Rebelrebellious]

Which is a better approach?

 

<?php // A
class one(){
function one(){
}
}

class two(){
function two(){
	$one = new one();
	one();
}
}

$two = new two();
$two->two();
?>

<?php // B
class one(){
function one(){
}
}

class two(){
$one = new one();
}

$two = new two();
$two->one->one();
?>

[shlumph]

Depends, are you sure you're always gonna call One if you create Two? Then A is the way to go. If you're not always gonna call one when you create two, then go with B.

[Daniel0]

The second example is invalid. You cannot execute code within the body of a class definition. It has to be within a method.

 

Neither are good though; they're both using the old PHP4 syntax for constructors.

[Maq]

Why don't you reference the manual - OOP?

[Rebelrebellious]

Thanks for taking a look Shlumph. By your logic I would actually expect to choose the opposite approaches to the respective goals. If i were always going to call one then I may as well just include it and call it as such. If I take approach A however I am only creating one if I need it and I have the option of changing method two to pull a different function altogether. Why do you suggest the opposite?

 

Daniel0,

You are right. I was just choosing the names for convenience, but they would be treated as constructors. In my actual program, the functions are named differently, they are not constructors. And now i understand why Shlumph thought the opposite.

 

Let me modify the question..

Which is better?

<?php // A
class one(){
function f(){
}
}

class two(){
function f(){
	$one = new one();
	$one->f();
}
}

$two = new two();
$two->f();
?>

<?php // B
class one(){
function f(){
}
}

class two(){
$one;

function f(){
$this->one = new one();
}
}

$two = new two();
$two->one->f();
?>

 

Thanks,

 

[Daniel0]

Your second example is still invalid. To declare a class property you must use the keyword var in PHP4 or one of the keywords public, private or protected (depending on the wanted visibility) in PHP5. I'd follow Maq's recommendation of reading the part of the manual concerning OOP.

 

In regards to best practice we cannot really tell which would be better. You'll have to come up with a concrete example to get a definite answer.

[Rebelrebellious]

Okay, I am not trying to ask about proper syntax here. I am asking about the approach to calling a class function by way of an intermediate object. The code was thrown together, poorly, to demonstrate the situation in a general way. Here is another revision.

 

<?php // A
class one(){
function f(){
}
}

class two(){
function f(){
	$one = new one();
	$one->f();
}
}

$two = new two();
$two->f();
?>

 

<?php // B
class one(){
function f(){
}
}

class two(){
public $one;

function __construct(){ 
	$this->one = new one();
}
}

$two = new two();
$two->one->f();
?>

 

[Daniel0]

Well, your code snippets don't make any sense, really. In neither of the examples do the class one accomplish anything and are as such redundant. Again, I'm afraid you'll have to come up with a concrete example before we can begin to talk about best practice. Without knowing what purpose the methods and classes serve it's impossible to tell which course of action would be superior.

[Rebelrebellious]

Thanks for taking the time to help me with this. I am amused that you can't imagine that the function in class one does something. I think you are amused because you can. I'll humor you a little further.

 

<?php // A
class one(){
protected $type;

function __construct($type){
	$this->type = $type;
}

function f(){
	// query the database about one and return specific information about f where type
}
}

class two(){
function f(){
	$one = new one('example');
	$one->f();
}
}

$two = new two();
$two->f();
?>

 

<?php // B
class one(){
protected $type;

function __construct($type){
	$this->type = $type;
}

function f(){
	// query the database about one and return specific information about f where type
}
}

class two(){
public $one;

function __construct(){ 
	$this->one = new one('example');
}
}

$two = new two();
$two->one->f();
?>

 

 

[shlumph]

I think his examples are completely pseudo... I'm thinking he wants to know if he should instantiate an object and execute a method of that object in a separate classes' constructor, or just create an instance of an object in a separate classes' constructor.

[Rebelrebellious]

You may want to imagine the word 'one' = 'part' and the word 'two' = 'whole' or some similar analogy.

 

[Daniel0]

Thanks for taking the time to help me with this. I am amused that you can't imagine that the function in class one does something. I think you are amused because you can. I'll humor you a little further.

 

Nope, I'm being 100% honest. Either of those could be the best depending on what you're trying to do.

 

In your latest example it appears that two in example two is a factory. Even then, without two's role being clear it's not possible to determine the best practice, though it would indicate that in this particular case example two is.

 

Trust me when I say that best practice cannot be determined without a context.

[Rebelrebellious]

Well we are getting somewhere. In both cases I am using the object $two as the object that handles all of the logic. two works with one and a bunch of other objects within its functions. In this situation however, two merely needs to present ones function without doing anything with the results. I could go straight to one and bypass two as a case C. Thanks again everyone.

 

[Daniel0]

In both cases I am using the object $two as the object that handles all of the logic.

 

Well, that's definitely a no-go. This means you are creating inter-object dependencies which sort of counters OOP's decoupling concepts.

[Rebelrebellious]

I'm not sure if there is a dependency. Whether I use case A, B, or C the function is still in object one. The point of object two is that I only need to instantiate the biggest object on the page that has the display stuff on it. So my page can be something like:

 

<html>
...
<body>
<?php
include_once 'file containing two';
$two = new two;
?>
</body>
</html>

 

Two is sort of like a zoo and one is like a gorilla. two gives me access to all the zoo functions and the cow gorilla interaction functions and the gorilla functions. I could instantiate a gorilla in the display page and get its functions directly but I am thinking that it makes more sense to interact with either zoo->gorilla_function() or zoo->gorilla->gorilla_function();

 

Does this make sense?

 

 

[Rebelrebellious]

Thanks everyone. I am looking forward to reading your wisdom on Monday. Have a great weekend.

[Daniel0]

Uhm... well, you see, for the most part, in aggregation the containing object shouldn't be concerned with the instantiation of the contained object. Otherwise you create a dependency issue.

 

Consider the following definitions:

abstract class Animal
{
private $name;
public function __construct($name)
{
	$this->name = $name;
}
public function getName()
{
	return $this->name;
}
}
class Monkey extends Animal {}
class Elephant extends Animal {}

 

Now imagine this:

class Zoo
{
private $animals = array();

public function __construct()
{
	$this->animals[] = new Monkey('Joe');
	$this->animals[] = new Elephant('Jack');
}
}

$zoo = new Zoo();

 

Now consider the following instead:

class Zoo
{
private $animals = array();

public function addAnimal(Animal $animal)
{
	$this->animals[] = $animal;
	return $this;
}
}

$zoo = new Zoo();
$zoo->addAnimal(new Monkey('Joe'))
->addAnimal(new Elephant('Jack'));

 

What's the difference? Both result in Zoo having the same animals, you could say that Zoo has the same state in both instances.

 

In the first example the zoo is dependent on Monkey and Elephant. In the second example the zoo has has the individual animals passed to it. This decouples the elements is thus better designed. The latter example is called aggregation. There is another thing called composition.

 

Essentially, the difference between composition and aggregation is that with composition, when the owning object ceases to exist, so do the contained objects. In aggregation that's not the case, the contained objects will persist even if the containing object doesn't. Now, in terms of your zoo, the latter would be more true to real life seeing as it uses composition whereas the former uses composition. If a zoo closes in real life, then it doesn't automatically mean that all the animals in the zoo will die. In OOP you can say that you are modeling the world using objects that represent real life entities.

 

Of course you cannot decouple all classes from all classes. That wouldn't be a natural system. Some things are logically connected to each other. The idea is, however, to avoid establishing unnecessary dependencies in your application because that could result in maintainability and portability issues.

[Rebelrebellious]

That helps a lot. Now I have a better concept of what situation calls for what approach. Thank you,