OOD/OOP best practice question

To the original poster:
[Cue instruction video music]
[1950' looking gentleman with slicked back hair holding a pipe walks in]
...and as you can see from this thread, this is why we have standards and best practices. They clear up all the confusion and eliminate inconsistencies in coding practices...

LMFAO ;)

yeah, and as you can see, very few are clear on what those standards are...=)

Quote:

---

Originally Posted by Cimmerian

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

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

---

I think it was misleading what I said, sorry for the confusion :)
It all depends what kind of classes we are talking about and what the classes do. If we have class B, which contains properties for an object, then we can call class B from class A and give properties to an object in class. Class A on the other hand will communicate with the Document class. However, class A cannot do anything with an object on the root directly, because the root is private. Only the Document class can. All the control is from the Document class.

A Flash movie becomes like a Flex movie.

Quote:

---

However, class A cannot do anything with an object on the root directly, because the root is private.

---

But it only have to be private if you make it private, inst it?And even if you cant unprivatize it, thats what getters and setters are for inst it?

The way i see the (former) main timeline,or the document class, is a class that can do anything, can know anything, know all the public methods of any other classes, set the listeners for events from any other class, and you can change it to anything you want to get your job done
And thats not suposed to be bad design
http://www.kirupa.com/forum/showthre...21#post2167721

Quote:

---

Originally Posted by senocular

You need to have classes that are tools for an outside class where that outisde class uses and digs into to make that other class work for it. And that outside class might be tool for another class using it and so on and so forth until eventually you get to your root or document class, the root node of the Flash movie or application in which everything is defined - the very class that has absolute immediate access to stage and root.

---

Quote:

---

The way i see the (former) main timeline,or the document class, is a class that can do anything, can know anything, know all the public methods of any other classes, set the listeners for events from any other class, and you can change it to anything you want to get your job done
And thats not suposed to be bad design

---

Yeah the document class is pretty much the flash version of public static void main in java. This is where you kick the program off and tie the whole thing together, so some of the rules that apply to designing classes in general ,do not necessarily apply to the doc class (as the doc class is the specific implementation).

I took the approach of using the document class to instantiate all other classes and that was basically it. From there, all the classes communicate directly. I think the design you guys mentioned is better, where the document class adjusts to compensate, it just seemed like I was going to write more lines of code and I didn't have time to do that right now!

---

That's basically the original method of programming. Object oriented should have none on the "horizontal" communication and has the benefit of being able to pretty much pick up an object and put use it again in any other program, or maybe elsewhere in the same program.
The objects do what they need to without being tied down by the other objects.

Doing it that way has it's ups and has it's downs.
With OOP I could use the same ball class for pong, breakout, a cannon simulator, or even in some RPG but the downside is that I'm going to have to spend a lot more time programming it with functions that make it a ball rather than "a pong ball" or "a cannon ball."
You don't program the ball to hop one square left when the player pushes from the other side, you don't program it to reflect off of a wall when it hits one.

The player and walls are not children of the ball so the ball doesn't know that it has to interact with them. The parent that contains both of these things knows what their relation to each other is so the parent tells the ball what to do when something happens.
Well, not what to do exactly- the parent tells it which thing to do. The ball already knows how to do it.

...I might be mixing things up here so I'm just going to stop before I make anything worse.

no, you're exactly right! I know I took a more "procedural" approach to OOP, and I'm not in love with it, but I felt like I could get it done faster. In the long run, true OOP is better in my opinion. But I'd be lying if I said I was anywhere near a master OO programmer. One day.

The sad thing is, I've probably learned more about OOP in THIS THREAD than I did in 4 YEARS OF COLLEGE GETTING MY CS DEGREE! Too much theory, not enough real-world application.