Menu
Community /Pin to ProfileBookmark
@NogDogMay 08.2012 — #If it's not a parent:: issue as Alan suggested, then we may need a few more details about what actually needs to happen. Perhaps you'll need to pass $this as a parameter to the "small object", which it would then pass to its parent?
Though this sort of circularity would make me think twice about this part of the application architecture. ?@NogDogMay 09.2012 — #Hundreds of small objects from the same class probably does not really do anything significantly more processing-wise than creating the same number of arrays. If each object were derived from a different class and thus required 100 different class definition files to be require()'d, I might be a little worried, but even then that sort of performance issue is generally lost in the noise compared to data issues. While it never hurts to at least briefly consider performance issues at this level, the danger is spending a lot of time fiddling with it only to find the PHP parser/compiler does a better job of optimizing things than you do. ?@NogDogMay 09.2012 — #There is probably a [I]little[/I] overhead, but it's nothing I've ever worried about; but if you ever get the sort of traffic load where it would actually matter, you can probably afford a 2nd server along with a load-balancer. (Hardware is cheap these days compared to paying programmers for weeks/months of debugging code that is poorly designed/written. ? )
For that matter, PHP arrays are somewhat notorious for using excessive memory (at least in some people's view), so you may still be ahead of the curve by creating objects custom-designed for the specific data you want to store/manipulate -- again pointing to the fact that fiddling around with micro-optimizations can be tricky and sometimes counter-intuitive. (If you really need to worry about every micro-second for a missile guidance system or such, you probably shouldn't be using PHP anyway. ? )
Ultimately, I'm generally in favor of designing/coding for maintainability, and worrying about optimization only if/when you find you need it (though you always have it sort of kicking around in the back of your brain to make sure you aren't doing anything really stupid).
Please help with Objects
I have two seperate main classes for different parts of a website.
Both classes are used to make a single object each.
Each of those objects utilizes a shared “sub”class to make lots of small objects that are used for easy storage and retrieval of data.
To keep them clean and small these “sub”objects call back to the parent in when more complex methods need to be run.
Problem is thus.
How do I:
refer back to the objects creator in order to access its methods?
Sign in
to post a comment8 Comments(s) ↴
0
@NogDogMay 08.2012 — #If it's not a parent:: issue as Alan suggested, then we may need a few more details about what actually needs to happen. Perhaps you'll need to pass $this as a parameter to the "small object", which it would then pass to its parent?[code=php]
<?php
class TheParent
{
public function test(iFoo $foo)
{
return $foo->getText();
}
}
class TheChild extends TheParent
{
public $name = 'World';
}
interface iFoo
{
public function getText();
}
class Foo implements iFoo
{
private $obj;
public function getText()
{
return "Hello, " . $this->obj->name;
}
public function createObject()
{
$this->obj = new TheChild();
}
public function useObject()
{
echo $this->obj->test($this);
}
}
$foo = new Foo();
$foo->createObject();
$foo->useObject();
[/code]Though this sort of circularity would make me think twice about this part of the application architecture. ?
0
@NogDogMay 09.2012 — #Hundreds of small objects from the same class probably does not really do anything significantly more processing-wise than creating the same number of arrays. If each object were derived from a different class and thus required 100 different class definition files to be require()'d, I might be a little worried, but even then that sort of performance issue is generally lost in the noise compared to data issues. While it never hurts to at least briefly consider performance issues at this level, the danger is spending a lot of time fiddling with it only to find the PHP parser/compiler does a better job of optimizing things than you do. ?0
@NogDogMay 09.2012 — #There is probably a [I]little[/I] overhead, but it's nothing I've ever worried about; but if you ever get the sort of traffic load where it would actually matter, you can probably afford a 2nd server along with a load-balancer. (Hardware is cheap these days compared to paying programmers for weeks/months of debugging code that is poorly designed/written. ? )For that matter, PHP arrays are somewhat notorious for using excessive memory (at least in some people's view), so you may still be ahead of the curve by creating objects custom-designed for the specific data you want to store/manipulate -- again pointing to the fact that fiddling around with micro-optimizations can be tricky and sometimes counter-intuitive. (If you really need to worry about every micro-second for a missile guidance system or such, you probably shouldn't be using PHP anyway. ? )
Ultimately, I'm generally in favor of designing/coding for maintainability, and worrying about optimization only if/when you find you need it (though you always have it sort of kicking around in the back of your brain to make sure you aren't doing anything really stupid).