OOD/OOP best practice question

[5TonsOfFlax]

If your document class is Main.as, and you've got a public static var _root in it which points to itself, you can access it like this, from any class which imports Main.

Main._root

Once you have that, you can access any of its public variables or methods. If the instance of class2 is in a property of main called "c2", you can get that from the class1 instance like:

Main._root.c2

Note that it must actually be a property to access this way, not just a child.

Is it good design? for some applications, sure.

[Cimmerian]

but how does Class 1 talk directly to Class 2?

IF you are not making something to be reused one million times
give Class1 a reference to Class2

//inside Class1
var refToClass2:Object;
public function Class1(rf){
refToClass2 = rf;
}

public funcition makeThemWork(){
refToClass2.workDamU();
}

//inside Class2
public function workDamU(){
trace("im working im working!");
}

For now im thinking that it does not worth make everything just in case as if you were to reuse everything, when you will reuse a class you already know that before type the first line

[cancerinform]

this goes back to my diagram...I know how to communicate between my doc class and other classes, but how does Class 1 talk directly to Class 2? if you can use "_root" to do it in this way, how? also, if you can do it this way, that means you have to import your doc class or "Controller" class into every class that needs interaction, is that correct?

thx again, just trying to gain understanding!

PS...as a follow-up, I've tried accessing an object of Class 2 instantiated in my doc class (Main) from Class 1 using every possible combination of:

root.obj
this.obj
root.parent.obj
parent.root.obj

and anything else I could think of...I keep getting:

ReferenceError: Error #1069: Property obj not found on Main and there is no default value.

I have a variable in Class 2 called "timeline" which is an alias for the document class' "this" and I have no problem using it except when trying to communicate to other objects!!! plz advise!

To the first question: Everything is a matter of timing and events. The Arrange class is only there to set the movie and get the movie going. There will be no talk back from any class. The other classes talk over Eventdispatchers. In order to transfer variable values you would use getters and setters or public static variables.

To the errors you get:
When you call the variables they are null. If you look at the Arrange class there is an Eventdispatcher, which listens to when the root of the class is established. Then the objects can be placed and can be accessed from other classes.

[absolutezero342]

thx for the timely reply, all of you! I'm going to try some of these approaches out. thx again!

[absolutezero342]

I got it to work thank GOD! thx everyone!

Last Question...definitely:

if you don't take the approach I'm taking of having Class 1 & Class 2 communicate directly, then you're stuck using one class (ie. cancerinform's "Controller" class) facilitating everything and it seems like you wind up writing more code...what is the best approach (OOD-wise) for a very complex program? having class objects communicate directly or using one class to facilitate everything? Or is there a 3rd approach I've missed...I guess you could make a hybrid of the 2 approaches but that would seem messy???

[kortex]

Is seems like the underlying theme that is being discussed is the idea of loose coupling. Classes should depend on other specific classes as little as possible. Hence creating a class that requires another specific class to be passed to it is said to create a tight coupling between the classes (i.e., they depend on each other to function)
Polymorphism is one way this is dealt with (any sub class should be able to be substituted for its parent class without breaking code). With this approach, you can then create a class that requires a high level class (such as display object) rather than requiring a more specific subclass (such as movie clip), since in theory you should be able to substitute any thing that extends display object for a display object (and since it extends display object, the type checking will accept it if you type the parameter as a display object).

With this approach, you then do have to be sure that what you want to do in the class that this reference is being passed to relies only on things that are common to display class objects (or the highest level class that you types the parameter to) and not any thing specific to a given subclass.

Another approach is to parameterize for data and not classes. In other words store the data you need to pass in class 1 and pass the data instead of the whole class to class 2.

Every approach has its strengths and weaknesses are part of what you are doing as a programmer is to decide what the particular problem at hand warrants.

[Shokushu]

If you declare the class 2 object as public then you could do something like parent.class_2_object.variable/function; if you want to go the object route.

If you just care about putting the program together you can put a reference to you class 1 object inside of your class 2 object.

Just have a function that accepts the object type class 1 is or an array that includes it in one of it's slots or whatever.
Then if you want to make it permanent in the class then have a member variable and set it equal to the variable you passed in.

Then just use the member variable the way you would in the document class.

package
{
  import whatever
  public class Class_B
  {
      public var siblings_array:Array = new Array();

      public function Class_B (siblings:Array):void
      {
          this.siblings_array = siblings
      }

      public function something_else():void
      {
          this.siblings_array[1].some_function_in_class_1();
      }
  }
}

Clear enough?

Edit: Oh, I didn't realize there was a second page.

parent.make_class_2_do_something(mystery_parameter);

//in parent

protected function make_class_2_do_something(thing);
{
  class_2_object.do_something(thing);
}

It does end up being more code but if you want to re-use one of your classes you just need a function in the parent with the same name... which has also been said ._.;
I'll just stop talking now.

[absolutezero342]

no thx, I appreciate it...I guess we can put this thread to bed (no rhyme intended =) )

it doesn't look like there is a "BEST" way (at least not from what I'm hearing), but there are alot of options depending on the route one wants to take.
Thx again everyone!

[kortex]

Exactly (recalls some saying about skinning a cat...)

[cancerinform]

I took out the word "Resolved", because this thread is anything else than resolved unless we are the Flash Gods who know the truth

One thing, which I never liked about my own approach is that creating a public root makes it vulnerable to invaders. One of the important principles in programming is encapsulation. To achieve that we have to follow the Flex model. We create one Document class and any other class will communicate with the Document class. If we want to change objects and want a helper class to do that, then we pass the object as a parameter. This would mean, however, that if we have a Document class and class A and class B, that A and B can communicate with the Document class but A and B cannot communicate, in case an object on root has to be changed. This would be similar to the Tree model, where the stem and the root are the Document class.
So an alternative model is to create one main class and basically write everything in that class and use helper classes for effects and other things.

[691175002]

The best design decision depends on your goals. If you foresee something being changed or expanded in the future, make room to expand it. Otherwise you are just wasting time.

I am personally against the idea of a global access point such as a static root. It is unnecessary and breaks the encapsulation of the entire program. It isn't a big deal when only one or two people are programming, however the idea of OOP is to be able to finish something and know that its integrity will not be compromised accidentally.

With a global root, it is too easy for someone who does not know what they are doing to completely mess up the main program.

[absolutezero342]

ok, interesting points...but to avoid a situation like cancerinform described, where A & B cannot communicate directly (only through Document class), using a public static var to access the root is the only workaround anyone has come up with (at least in this thread). I really needed that to happen so using the public static var solution has been my best approach.

So an alternative model is to create one main class and basically write everything in that class and use helper classes for effects and other things.

get ready for one MONSTER document class...to create a class that does something really meaningful in my case, I need access to other classes, if for nothing other than to access data (ie. getters/setters).

[kortex]

get ready for one MONSTER document class...to create a class that does something really meaningful in my case, I need access to other classes, if for nothing other than to access data (ie. getters/setters).

I may have missed something (god knows it has happened before), but if the document class has an instance of both class a and class b, the is nothing stopping you from passing data back and forth between the two within the document class. You would have access to an of the public methods of any of the helper classes you instantiate in the document class. And doing it in this method means that none of your helper classes need to know about each other (only the document class does), and you can pass whatever data you need to back and forth with out requiring that a specific class is required by any of the helper classes (you program to the data needed in each class without having to pass a specific type of class and use getters to pass the data back and forth).

So I am just curious why does the document class method not do what you need (size argument aside)?

[absolutezero342]

yeah, it can be done, I guess I didn't like how clouded my document class was getting....seemed like I needed 2-3 times the code to do what I wanted to do.

[kortex]

Well think of it this way, the document class is a mess so that your other don't have to be.

[Cimmerian]

I did not understand that

If we want to change objects and want a helper class to do that, then we pass the object as a parameter. This would mean, however, that if we have a Document class and class A and class B, that A and B can communicate with the Document class but A and B cannot communicate, in case an object on root has to be changed.

I mean, if you create classA wich the only pourpose in life is to change classB,why on earth they need the root for it?AS3 itself have some classes that does that without anything between the two
Can you post an example of :'A and B can communicate with the Document class but A and B cannot communicate, in case an object on root has to be changed. ' ? I didnt uderstand that too

[derari]

It seems like you need a good design pattern...
Can you explain that communication more precicely?

[Shokushu]

I did not understand that

I mean, if you create classA wich the only pourpose in life is to change classB,why on earth they need the root for it?AS3 itself have some classes that does that without anything between the two
Can you post an example of :'A and B can communicate with the Document class but A and B cannot communicate, in case an object on root has to be changed. ' ? I didnt uderstand that too

The example code I posted basically shows it.

//in class 1
parent.make_class_2_do_something(mystery_parameter);

//in parent

protected function make_class_2_do_something(thing);
{
  class_2_object.do_something(thing);
}

So you can see that class 1 is just communicating with the parent. The parent then communicates with class 2.

[691175002]

That is overcomplicated and unnecessary.

It depends on the situation, but why cant class 1 contain class 2? There should be almost no instances of a child object telling its parent what to do aside from callbacks. It is completely unnecessary, breaks the encapsulation of the parent and causes you to wind commands through a maze of methods like you are now.

[Cimmerian]

And what is that object in root that cant be changed?

that if we have a Document class and class A and class B, that A and B can communicate with the Document class but A and B cannot communicate, in case an object on root has to be changed

Why it would not work?...is this object is the one that makes the communication?