Anyway I was wondering, what's the more "proper" way to go about accessing a method from an object that is being held by another object?
What I mean is I am accessing code in my program like this.
Object1.Object2.goToMethod(); where Object1 contains Object2 which contains goToMethod().
I find that if I make Object2 private in object 1, that it breaks the way I am doing this (which I expect).
Is it ok to do it the way I am doing it? Or would it be better to do something like the following?
Object2 = Object1.getObject2(); // where Object2 is returned by the method Object2.goToMethod();
Which way is better? Right now I'm the sole developer on this project (Just a fun side project I'm working on because I've always wanted to see it done) so I'm not too worried about somewhat messy code (its not all that bad. I can understand it, and its leglible enough to me), although I do see the other way being more readable but on the other hand (since Object1 has a lot of objects), its kind of a lot of overhead.
I apologize if this is not a simple question (to me it is though, classes/objects are pretty basic, just have to keep everything in memory with regards to what you're doing/what interacts with what/etc).
You mean do you allow direct access to methods of fields? Try googling for something called the "law of Demeter;" the Wikipedia article seems quite good.
What I think you want is something like this:Do you write 1: myCar.getEngine().start(); or 2: Engine yourEngine = myCar.getEngine(); yourEngine.start(); or do you write 3: myCar.startEngine(); ?
A lot of people would prefer "myCar.startEngine();" so what you do is to add a method in Car like this:All three approaches would work, but I think the third approach makes for easier code to read, and (as it says in Wikipedia) allows the Car class to keep its "private" members "private." I don't think there is that much difference between No 1 and No 2 really.
Yes, sorry. Direct field access. I see how doing it the other way is much better in the longrun. Thanks.
Um, related question. Should I make instance variables private or protected in a super class if a subclass will need them?
Making them protected means that I don't have to type "getVariable()" for something it should know (or have, since its extended), but is assuming the subclass knows the fields in the superclass an ok way of doing it, or is it better to make it private and say "getVariable()" if the subclass needs access to its super class instance variable?
Sorry for not replying earlier; I wanted time to think about your question.
If you already have public "get" methods to private fields you might as well use them for access from subclasses. Remember that protected members are accessible to other classes in the same package, as well as subclasses, so using "protected" doesn't restrict access as much as we sometimes would like. Difficult to be certain, but I think I would probably prefer the get methods. Of course, a subclass extends a superclass, so most of the calls can be done in the superclass; the subclass may not need lots of access to superclass fields.
I'd agree that 1 and 2 are far worse than 3. If a field is private and you have public method to send the field out of the object scope, that private constrain becomes just meaningless and its a bad habit. Keep private as private, provide a wrapper method (adapter design pattern) to access them is the right way to go.