Mvc / oop

Hello coders,

I'm having a problem with the concept of MVC and OOP. I have built a GUI form with various portions and I'm trying to update it from another class. I'm having difficulty accessing it. I understand the idea of accessing a child:

Code:

---

someclass Thing = new someclass();
Thing.doWhatever();

---

... but how do you access it when you're NOT in the class that spawned it? I was thinking that I have to pass something common, ie a parent class, and access it like:
me.parent.otherChild.whatever();

Problem is that the program starts up from a static class (main), so I can't pass anything (keyword "this" doesn't work from a static class). I also can't start a timer or anything else non-static, so I have to separate out my main code into another class called "program." In that I can run timers and whatever else I want as it's constructor is non-static. I think that's where the majority of my code will be, if only I can figure out how to access the GUI again.

My structure:
main.class = spawns GUI, spawns program.class instance "Program whatever = new Program()"
program.class = starts a timer, other code, etc.

Quote:

---

I understand the idea of accessing a child:

Code:

---

someclass Thing = new someclass();
Thing.doWhatever();

---

---

The code you have posted under this statement has nothing to do with child-parent relationship or inheritance. Please clarify and/or correct.

Quote:

---

I was thinking that I have to pass something common, ie a parent class, and access it like:

Code:

---

me.parent.otherChild.whatever();

---

---

This statement above isn't clear. What does parent/child relationship have to do with any of this? Again, please clarify your meaning.

Quote:

---

Problem is that the program starts up from a static class (main), so I can't pass anything (keyword "this" doesn't work from a static class). I also can't start a timer or anything else non-static, so I have to separate out my main code into another class called "program." In that I can run timers and whatever else I want as it's constructor is non-static. I think that's where the majority of my code will be, if only I can figure out how to access the GUI again.

---

Again this is confusing. All code starts from main, and yes of course you can create and initiate objects such as Timers from within main. Again, please correct or clarify.

Also, you may be mixing the concepts of inheritance with that of intra-class communication, and you need to know that one thing has nothing to do with another. So don't think in terms of parent and child, but instead simply of two or more classes that need to talk to each other, period. In order to be successful with that one or both classes have to have a reference to the other so that it may call methods on the other active object, and often this reference is passed via a constructor parameter or setter (mutator) method parameter.

Of course all of your code starts from the static main, and often in this method you will create your two objects and then pass a reference of at least one of the objects to another. For instance if you were passing references from both to each other:

Code:

---

public static void main(String[] args) {
  ThisClass thisObject = new ThisClass();
  OtherClass otherObject = new OtherClass();

  thisObject.setOtherClass(otherObject);
  otherObject.setThisClass(thisObject);
}

---

Of course ThisClass and OtherClass will both need public setXXX methods for this to work and private variables to set.

My apologies, but I view terminology a bit different. I've always thought of things in my own terms, and once in a while it causes problems in communication like this!

When I referenced Thing.doWhatever(), I wasn't referring to class inheritance and children in that sense, but in terms of local variables/etc. I consider something to be a "child" of something if it is spawned locally and can only be accessed by that method/class/etc. It reminds me a lot of having a "child" in a sense, so I refer to it as that.

Your example works and I'm incorporating it now. I was under the impression there had to be an easier way to access another class, as this seems inefficient to me. The fact I'd have to explicitly tell every single class about anything else it needs is a bit... odd. I'd want each class to be aware of all others within the program. Security would then be created through public/private attributes... but that may be a very naive statement, so :P:

Thanks for the help!

Quote:

---

Originally Posted by trader5050

My apologies, but I view terminology a bit different. I've always thought of things in my own terms, and once in a while it causes problems in communication like this!

When I referenced Thing.doWhatever(), I wasn't referring to class inheritance and children in that sense, but in terms of local variables/etc. I consider something to be a "child" of something if it is spawned locally and can only be accessed by that method/class/etc. It reminds me a lot of having a "child" in a sense, so I refer to it as that.

---

parent-child has a very specific meaning when referring to Object-Oriented Programming, and another meaning sometimes used in grouping of GUI components, so you must be very careful when using these terms that you are completely clear in what you mean. Since you are not referring to either of these two situations that I mentioned I would further recommend that you avoid use of "parent-child" entirely.

Quote:

---

Your example works and I'm incorporating it now. I was under the impression there had to be an easier way to access another class, as this seems inefficient to me. The fact I'd have to explicitly tell every single class about anything else it needs is a bit... odd. I'd want each class to be aware of all others within the program. Security would then be created through public/private attributes... but that may be a very naive statement, so :P:

---

I don't understand your objections or what sort of hardship passing a reference could bring to your code. Again, please clarify your problem. You will want to minimize your communication between classes, so you aren't going to have to tell "every single class about anything else it needs...".