Instantiate a Class through a constructor argument of another class.

Question

public function LevelManager(owner:Home)
                              _owner = owner;
In my LevelManager Class I have the above code in the constructor. Home is another Class which is not instantiated anywhere with the new keyword. It is merely a parameter in the constructor and then passed into the body and assigned to a local variable. I didn't know you could instantiate a class through a function parameter. Is that right???
Cheers in advance.

Answer 1

Well, I know Amy is big on design patterns and she is going to slap me but I am the guy who is not a big fun of DPs in regular Flash applications. I have many reasons to dislike them.
I am not against DPs in principal. In collaborative environments (big teams) or in situations when software is developed for industrial consumption or as partially closed frameworks - it makes sense. Otherwise - they are just possible solutions and reference point at best. In Flash they frequently are major silly overkills. They are more of academic than practical value contrary to what people tend to believe.
Design patterns are possible solutions that developers came up with heuristically base on the problems they needed to solve - not vice versa. Problems do not dictate design patterns.
There is a strong tendency among DPs proponents and followers to make DPs self-fulfilling prophecies. Instead of conceptualizing of particular application needs developers often are searching for DP first and then try to squeeze logic into a particular or a group of several design patterns.
If a person is taught that DPs is the only way to go - there is a great danger of killing creativity and the thought process.
I strongly believe that what makes a star programmer is the ability to conceptualize the project, model it well and only then find coding solutions based on language capacities. And to question any suggestions in favor of current task efficiencies.
By the same token, if your painting doesn't need color red - why use it? This is another thing that happens often - developers implement something that is actually not needed.
Code is cheap! When project is well conceived and modeled - coding takes very little time. One ends up with his/her own "design pattern" that may or may not fall into one of DPs that is articulated already.
Also, there is a great deal of activism around DPs that, as with any activism, forms an ideology that is full of misleading simplifications.
First one is that OOP is equated to DPs usage. This is totally dangerously  untrue!!!
Another one is you mentioned. Spaghetti coding is not the only alternative to design patterns. In other words, if one doesn't use DP - it absolutely doesn't mean person is engaged in spaghetti coding. And vice versa - DP does not shield program from spaghetti coding. I have seen DP warriors going crazy with spaghetti coding although DP was implemented to the tee.
Another example of misconception is that DP proponents always carry banners of decoupling and modularization. Be very skeptical when someone gives you this shpeal. Modularization is easy to conceal for "propaganda" purposes and it is comfortable not to think about when DPs are used (especially MVC concept). Since this is just a concept - there are no real checks and balances.
Decoupling, on the other hand, is not that easy to shove down someone's throat. Decoupling can be actually calculated - this is where a lot of idealistic beliefs that someone's code is well decoupled because of the DP fails miserably. Not because of DP itself but because of implementation. Well, sometimes pattern too.
See, there is no black and white again.
My point is that DPs do not protect anyone from any kind of challenges or mistakes as they don't make a better programmer. They can make one a disciplined follower but not a real creator (not that everyone must be the Creator).
If not used properly DPs may be a ground for crappy inefficient un-scalable application as much as any other approach.
And the last thing. I said that DPs are special suspects in Flash. This is because ActionScript and Flash are already limited frameworks that force us into thinking in MVC terms. This is just a nature of the beast. To attempt to warp it up into another MVC framework looks like a self-indulgent irrelevant academic activity to me.
And I did not even mentioned practicalities of the target environments we develop our applications for.