Aggregation
I have a class "System" within which there are 2 other classes "class1" and "class2" (The classes are private instance variables of the main class "System"). Class "System" has another private instance variable say "private int var". There is a getter method and a setter method to get and set the value of the variable "var". Classes "class1" and "class2" should be able to access the variable "var" through class "System"'s methods .To be possible, an object of type "System" has to be instanciated first.
public class System {
private Class1 c1 ;
private Class2 c2 ;
private int var ;
public int getVar () {return var;}
public void setVar (int var) {this.var = var ; }
public System () {
var = 100 ;
c1 = new Class1 () ;
c2 = new Class2 () ;
}
public static void main ( String [] aregs ) {
System app = new System () ;
}
} // end of class System
Now, how can "c1" and "c2" access "var" ? Is there anything wrong with the design?
[1036 byte] By [
Emilie_81] at [2007-9-30 18:02:42]
1) Class1 and Class2 could be made non-static inner classes
2) var could be given an access method of at least package level and Class1, and Class2 could be passed in the System ojbect to their constructor (new Class1(this) ... where this is an instance of System)
3) Class1 and Class2 could be passed var directly to their constructor (new Class1(var))
Without knowing what you are trying to accomplish with this design it is hard to say if it is good or not, but it seems fishy.
steve - http://www.jamonapi.com
"Var" value keeps changing, and passing that variable to class2's constrcutor would NOT allow the class to keep track of the changing values of "var", hence, class2 would use the wrong , non-updated value of var, whenever it needs it (e.g. during a repaint ). Passing "this" would lead us to the same point, i.e. non-updated values of an old copy of an instance !!
Is making "var" public static the only way to resolve this ? It won't be a good OO design. I don't wish to have all the classes access and modify "var" with no rerstrictions imposed at all ! It would leave a real mess behind !
<< Passing "this" would lead us to the same point, i.e. non-updated values of an old copy of an instance !!>>Being as java passes by reference, not by value the changed values would be reflected by passing the 'this' pointer.
> public class System {
>
> private Class1 c1 ;
> private Class2 c2 ;
> private int var ;
>
> public int getVar () {return var;}
> public void setVar (int var) {this.var = var ; }
>
> public System () {
> var = 100 ;
> c1 = new Class1 () ;
> c2 = new Class2 () ;
> }
>
> public static void main ( String [] aregs ) {
> System app = new System () ;
> }
> } // end of class System
>
> Now, how can "c1" and "c2" access "var" ?
The Class1 and Class2 objects can 'ask' a System object for the value of its 'var' field. They can do this by calling the getVar method of an instance of System.
> Is there anything wrong with the design?
Yes. There is no meaning to the class names, their purpose, what is being modelled, or what requirements are being met by the model. What are Class1 and Class2 going to do with the value of var? Something bad I bet!! If I was a System, I wouldn't give them nothing.
[snipped]
> Now, how can "c1" and "c2" access "var" ? Is there
> anything wrong with the design?
Assuming an aggregation is justified in this case, meaning c1 and c2 are supposed to be owned by System, then we can safely say that anything c1 and c2 is going to do is also always driven by System. Then it becomes quite clear that System can feed the value of var to c1 and update var after any call to c1 if needed. This way c1/c2 are completely decoupled from var.
--mr
> << Passing "this" would lead us to the same point,
> i.e. non-updated values of an old copy of an instance
> !!>>
> Being as java passes by reference, not by value the
> changed values would be reflected by passing the
> 'this' pointer.
>
Java passes by value.
> Being as java passes by reference, not by value the
> changed values would be reflected by passing the
> 'this' pointer.
>
Java is always pass-by-value. Always.
Always. Always. Always.
http://javadude.com/articles/passbyvalue.htm
http://java.sun.com/developer/JDCTechTips/2001/tt1009.html#tip1
http://www.javaranch.com/campfire/StoryPassBy.jsp
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
http://www-106.ibm.com/developerworks/library/j-praxis/pr1.html
http://www.cs.toronto.edu/~dianeh/tutorials/params/
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#38698
http://radio.javaranch.com/channel/val/2004/05/21/1085125887000.html
There is exactly one parameter passing mode in Java -- pass by value -- and that helps keep things simple.
-- James Gosling, "The Java Programming Language, Second Edition"
> > Being as java passes by reference, not by value the
> > changed values would be reflected by passing the
> > 'this' pointer.
> >
>
> Java is always pass-by-value. Always.
>
> Always. Always. Always.
>
> http://javadude.com/articles/passbyvalue.htm
> http://java.sun.com/developer/JDCTechTips/2001/tt1009.h
> ml#tip1
> http://www.javaranch.com/campfire/StoryPassBy.jsp
> http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa
> 0526-pass.html
> http://www-106.ibm.com/developerworks/library/j-praxis/
> r1.html
> http://www.cs.toronto.edu/~dianeh/tutorials/params/
> http://java.sun.com/docs/books/jls/second_edition/html/
> lasses.doc.html#38698
> http://radio.javaranch.com/channel/val/2004/05/21/10851
> 5887000.html
>
> There is exactly one parameter passing mode in Java
> -- pass by value -- and that helps keep things
> simple.
> -- James Gosling, "The Java Programming Language,
> Second Edition"
That's all true for all the reasons that you cite: but it's also confusingly misleading at a higher level.
The 'value' that you get for non-primitives is something (pretend its a memory address) that references the object pool. It is true that the JVM treats this as a value. Changing my instance of the value does not change the value itself -- the reference that was passed to me continues to indicate the same object that it did before I was invoked. My instance of that value may be changed to indicate a different object. This is classic pass-by-value as we all understand it.
OTOH: at the "looking at my java source code level", the JVM implicitely uses that 'value' to access the object in the object pool whenever I call methods or access members. So long as I haven't changed the local instance to a different value by reassigning the variable to a different object, my local changes to the indicated object are reflected outside my local scope. There is no syntax at the source code level with which I can differentiate between the value and the object in the pool that the value indicates (unlike C(++) where we can manipulate both the pointer and the pointee), so it becomes easy to glss over the distinction.
Java does pass everything by value, but some (most) of those values are implicitely deferenced most of the time. For most things that we do at the source code level, its easier to think of it as 'pass by reference', but its best to get to the point where you understand the difference between how the language works and how you work with the language.
Dave Hall
http://jga.sf.net/
dhall at 2007-7-6 18:32:45 >
> For most things that we do at the source code
> level, its easier to think of it as 'pass by
> reference', but its best to get to the point where you
> understand the difference between how the language
> works and how you work with the language.
>
I agree with the latter part of this sentence, but disagree with the former ("it's easier..."). I think once one understands the way Java works in this capacity, it's just as easy to think of passing references by value. As I mentioned in another thread, I think a few people get tripped up when they assume that passing a reference is the same thing as passing by reference; it looks like I'd be preaching to the choir if I repeated that it isn't the same thing. And where I disagree with your latter assertion is similar to where I disagree with Bruce Eckel (respectfully, of course - I should hope one day to have a fraction of his talent). Eckel states the distinction between PBR and PBV is less important than understanding that the copied reference you use inside a method points can modify the object still pointed to by the original reference (and this is what gives the impression of a PBR mechanism in Java). To me, failing to make that distinction results in a contortionist's explanation of why a swap function in Java won't work, or why reassigning the copied reference doesn't affect the original reference.
Good discussion, though - thanks!
It's my contention that "thinking" of Java as PBR for object references is less accurate and less useful than eliminating potential confusion by "knowing" how it actually works. Besides, I think Gosling's quote is pretty cool. :o)
If you've come from a C(++) background, where the distinction between working with values and working with references is critically important, then it certainly helps when working in Java to understand exactly whats going on. You're fairly likely to be working on programs or implementing algorithms where that distinction is important.
OTOH: if you've come from a Cobol/Basic/VB background where the concept is largely not implemented at all, then the distinction is probably a good thing to learn and understand, but for the most part not terribly relevant to the types of applications that you're probably developing in Java. It's likely that this distinction will be learned as part of a gaining larger understanding of what's really happening behind the scenes.
I know a lot of folks that are productive developers that could not describe this distinction -- it's just fine that they develop high level applications with a PBR mindset. I wouldn't want to implement the low level details that make all the magic work without the more complete and correct understanding, though.
dhall at 2007-7-6 18:32:45 >
> If you've come from a C(++) background, where the
> distinction between working with values and working
> with references is critically important, then it
> certainly helps when working in Java to understand
> exactly whats going on. You're fairly likely to be
> working on programs or implementing algorithms where
> that distinction is important.
>
> OTOH: if you've come from a Cobol/Basic/VB background
> where the concept is largely not implemented at all,
> then the distinction is probably a good thing to learn
> and understand, but for the most part not terribly
> relevant to the types of applications that you're
> probably developing in Java. It's likely that this
> distinction will be learned as part of a gaining
> larger understanding of what's really happening behind
> the scenes.
>
> I know a lot of folks that are productive developers
> that could not describe this distinction -- it's just
> fine that they develop high level applications with a
> PBR mindset. I wouldn't want to implement the low
> level details that make all the magic work without the
> more complete and correct understanding, though.
I agree somewhat. I came from c++ and programmed in Java for quite a while before I realized the distinction. But it is important, and if you don't wrap your head around it now, you can become confused about what your software is doing.
I'd rather let people know the truth, than hide it from them with the false notion of protecting them.
> OTOH: if you've come from a Cobol/Basic/VB background
> where the concept is largely not implemented at all...
?
I can't say much about COBOL, but VB offers both ByRef and ByVal keywords to indicate the respective parameter passing mechanisms...
In both your cases (C++ vs. COBOL/BASIC/VB) above you express that it's a "Good Thing"™ to learn how Java actually works, so it seems that we agree. I'd add a couple more cases; namely, a case that handles those persons learning Java as a first-time language, and a catch-all case comprised of folks who've come to Java by a path not mentioned above (e.g., Perl, PHP, SmallTalk, etc.). In all these cases, it's a good idea to understand that Java is always pass-by-value. This isn't a "low-level detail"; it's a fundamental aspect of how the language works.
