using variables from an imported package
hi,
so i now have a project in eclipse indigo that uses a handful of packages. there's my classes inside the various packages. now, i import package one into package two. here's the code:
Code:
package dire;
import galaxy.GalaxySevenSystemOnePlanetOne;
public class Moon {
public static void yes() {
galaxy.GalaxySevenSystemOnePlanetOne sopo = new galaxy.GalaxySevenSystemOnePlanetOne();
sopo.
}
}
but the sopo. doesn't list all the variables within galaxy.GalaxySevenSystemOnePlanetOne.
it would be great to get this working. do i have to declare every variable within galaxyGalaxySevenSystemOnePlanetOne as public? global variables are ""frowned upon, right?
thanks!
Re: using variables from an imported package
If you want to access Class A's variables from a class that exists in a different package, then the variables must be public. An alternative to this style is defining getter and setter methods for each variable in Class A.
Re: using variables from an imported package
well, getters and setters are somehow "evil" and public variables are supposedly "frowned" on... is it better to use just one package? meaing the use of source folders within one package?
this is important so that i can correctly structure my gui game!
Re: using variables from an imported package
You're right, disregard what I said. Apparently the need for getters and setters (as well as public instance fields) is a sign of bad OOP design.
Source and interesting read: Why getter and setter methods are evil - JavaWorld
Blanket judgements considered harmful
Quote:
Originally Posted by
awinston 
JavaWorld is reputable and this article is well worth reading.
That said, his previous article was called Why "extends" is evil and this one begins: I didn't intend to start an "is evil" series. Perhaps the author could have practised, in his writing, a little design. With respect to programming he talks about the dangers of acting out of habit (== "cliche" in language) and advises people to consider and be guided by the consequences of idioms they choose (in language these include the likely consequences in the minds of readers).
Frankly, I regard the "is evil" trope as tiresome and misleading.
Arguments of the form "OO is fundamentally f. X is not f. Therefore practitioners of X will burn in h3ll" are fundamentally bogus and backwards. The theologian's syllogism ought to be replaced by empirical observation. Various programming practices are found to be awkward and error prone, avoidance of these practices can be codified as patterns and OO emerges as nothing more than a conventional label for (some) such patterns.
(The author of the article is also author of numerous Big Books on Programming. We are reminded on this at the end of the article: like being reminded to drop something in the plate at the end of the sermon. To support the good fight. Or, by purchasing the book, to obtain the secret of Enternal Life for our APIs.)
-----
Despite the flat prose (it has all the elegance and punch of a powerpointed "presentation") and the adolescent appeal to argument-by-pidgeonholing and statistics ("an experienced OO designer could probably eliminate 99 percent of the accessors currently in your code") the points made are worth reading.
For more google "Law of Demeter".
Re: Blanket judgements considered harmful
Quote:
Originally Posted by
pbrockway2 Despite the flat prose (it has all the elegance and punch of a powerpointed "presentation") and the adolescent appeal to argument-by-pidgeonholing and statistics ("an experienced OO designer could probably eliminate 99 percent of the accessors currently in your code") the points made are worth reading.
Never underestimate the effect of a well-crafted powerpoint presentation :o:
Re: Blanket judgements considered harmful
Quote:
Originally Posted by
awinston Never underestimate the effect of a well-crafted powerpoint presentation :o:
Well I was feeling jaded this am when I posted that. I'm much more at ease with the world now, so I should really resist the temptation to observe that I wouldn't underestimate them because the impact of these magic lantern shows can't be underestimated.
I sometimes try to fight their soporific qualities by counting the grammatical and spelling errors. But the only thing that provides any real drama (if I haven't already fallen asleep) are those delightful moments when the presenter stands, befuddled and wordless, as technical assistance intervenes to correct a monitor which has gone to sleep or whatever.
That and those brave souls who attempt ... the embedded movie! Assuming the attempt isn't stillborn with some sort of missing link error the audience is now on the edge of their seats, you can sense the anticipation. Will the computer freeze? One is rarely disappointed.
As the hapless presenter mumbles "I knew I shouldn't have tried that" I have to fight the impulse to put down my crossword and respond from the back of the room: "No, you shouldn't have tried that. And don't bother rebooting the f*cking thing. Recognise that we're human beings and speak to us."
Re: using variables from an imported package
That sounds awful, but it was a very entertaining read :(clap):
I'm not sure what the setting of your story was, but in my high school classroom most of my peers really make an attempt (and succeed) to make a quality-presentation. That's not to say that bombs aren't dropped here, as well...the best is when each slide has 10,000 words (obviously all written by Partner A) and Partner B is struggling to read/pronounce the text while Partner A sheepishly looks at the teacher's shaking head and disappointed expression.
I'm not sure if this has hit New Zealand yet, but these are big when students want to make their presentation more "engaging": Prezi - The Zooming Presentation Editor
It usually results in the audience paying closer attention to the fancy animations rather than the content (which may actually be what the presenter wants?)
Re: using variables from an imported package
A bit further afield from the original topic, but a couple of weeks ago the president of the organization whose Google Sites web presence I created and maintain asked me to put together a presentation of the year's activities for the Annual General Meeting, which is next Sunday. I politely told him that PowerPoint and I don't get along very well, and asked him to get someone else to do it.
I *have* put together a PPT showcasing the site viewership over the first six months; no animation, no fancy colors, no transition effects. Just a header and a table, all the same size and color, on each of the 4 slides.
db
Re: using variables from an imported package
Quote:
I'm not sure what the setting of your story was
... also a highschool. The other side of the generational divide.
Teachers are among the most enthusiastic of those who buy in to this form of self "expression" where reason and analysis take a back seat to whatever is spat out on the first page of a Google image search. Where a vivid metaphor isn't rated as powerful as a cute font. Where a carefully crafted argument isn't worth the effort it (really does) take - not when an animation will do just as well.
It's expression in much the same way as McDonalds is cuisine.
-----
Yes, I've seen Prezi. I hate technology that other people control, however. So it inspired me to have a look what you might achieve with a little bit of Javascript and the fact that modern browsers render vector graphics. I imagine you could script something with JavaFX, too.
What all these programs lack is real interactivity. Prezi would be much better if ActionScript's potential were fully used to allow the embedding of functional applets.
Re: using variables from an imported package
Quote:
Originally Posted by
DarrylBurke A bit further afield from the original topic, but a couple of weeks ago the president of the organization whose Google Sites web presence I created and maintain asked me to put together a presentation of the year's activities for the Annual General Meeting, which is next Sunday. I politely told him that PowerPoint and I don't get along very well, and asked him to get someone else to do it.
I *have* put together a PPT showcasing the site viewership over the first six months; no animation, no fancy colors, no transition effects. Just a header and a table, all the same size and color, on each of the 4 slides.
db
And I was almost going to recommend you to winston as the person here who could whip something impressive with JavaFX!
I looked at JavaFX - basically I used a large canvas where clicks would take you from one section to another in parabolic arcs. The nice thing was that you can embed more or less anything including live web pages and applets. What seems to be missing (though I didn't look very hard) are decent libraries for handling graphics - rendering common vector graphic formats, drawing nicely shaded arrows and that sort of thing.
Re: Blanket judgements considered harmful
Quote:
Originally Posted by
pbrockway2 For more google "Law of Demeter".
I never know if I should like this law or not; have a look at this example snippet:
Code:
class A {
B b; // a B owned by A
void doSomething() {
b.getC().doSomething(); // bad according the LoD
}
}
class B {
C c; // a C owned by B
C getC() { return c; } // bad
}
class C {
void doSomething() { ... } // the target
}
The Law of Demeter forbids this: C is not a 'friend' of A so it shouldn'n 'speak' to it; the scenario above also has to use a getter, which is also ABT (A Bad Thing (tm)); the LoD suggests the following alternative:
Code:
class A {
B b; // a B owned by A
void doSomething() {
b.doSomething(); // fine according the LoD
}
}
class B {
C C; // a C owned by B
void doSomething() { c.doSomething(); } // fine according to LoD
}
class C {
void doSomething() { ... } // the target
}
If you come to think of it: those 'middle men' (here class B) are going to be stuffed with delegating methods (here from A to C). Those are just artefacts imho and I dislike that too ...
kind regards,
Jos
Re: Blanket judgements considered harmful
Quote:
Originally Posted by
JosAH I never know if I should like this law or not; have a look at this example snippet:
Code:
class A {
B b; // a B owned by A
void doSomething() {
b.getC().doSomething(); // bad according the LoD
}
}
class B {
C c; // a C owned by B
C getC() { return c; } // bad
}
class C {
void doSomething()
{ ... } // the target
}
The Law of Demeter forbids this: C is not a 'friend' of A so it shouldn'n 'speak' to it; the scenario above also has to use a getter, which is also ABT (A Bad Thing (tm)); the LoD suggests the following alternative:
Code:
class A {
B b; // a B owned by A
void doSomething() {
b.doSomething(); // fine according the LoD
}
}
class B {
C C; // a C owned by B
void doSomething() { c.doSomething(); } // fine according to LoD
}
class C {
void doSomething() { ... } // the target
}
If you come to think of it: those 'middle men' (here class B) are going to be stuffed with delegating methods (here from A to C). Those are just artefacts imho and I dislike that too ...
kind regards,
Jos
Except here is a (perhaps trivial) question that I have...in your second example, what would be a good name for B's doSomething() method? In fact, I'll add D in order to make my example more clear:
Code:
class A
{
B b; // a B owned by A
void doSomething()
{
b.doSomething(); // fine according the LoD
}
}
class B
{
C c; // a C owned by B
void doSomething()
{
c.doSomething(); // fine according to LoD
}
}
class C
{
D d; //a D owned by C
void doSomething()
{
d.printName();
}
}
class D
{
void printName()
{
... //the target.
}
}
We know that ultimately we want to call class D's printName() method. If we want to call printName(), then we also know that we should call class A's doSomething() method in order to trigger the execution of printName(). Does that mean that we should also give the name "printName" to class A's doSomething() method? And what would we name class B's doSomething() method and class C's doSomething() method?
It seems to me like it would be easier and less confusing to just have Class A be a friend of Class D in this case.
Re: using variables from an imported package
Your example doesn't solve anything according to that Law of Demeter; that law says that an object should only 'talk' to another object if it is a 'friend'; friends are objects that are created by the object (e.g. object A) or passed in as a parameter; 'friendship' isn't transitive (read: your friends are not necessarily my friends). So object C is a friend of object B and object B is a friend of object A but A shouldn't directly talk to C (as in the original example). So in my revised example object A talks to B and B talks to C; this totally decouples all 'non friend' objects and that is nice indeed but it needs a lot of 'pass through' delegating objects (as in B in my revised example); actual names of the methods don't matter. One could argue that both object A and B should have a reference to a single object C but I consider that an artefact too; I haven't made up my mind about that law yet ...
kind regards,
Jos
Re: using variables from an imported package
Quote:
Originally Posted by
JosAH Your example doesn't solve anything according to that Law of Demeter; that law says that an object should only 'talk' to another object if it is a 'friend'; friends are objects that are created by the object (e.g. object A) or passed in as a parameter; 'friendship' isn't transitive (read: your friends are not necessarily my friends).
In my example Class A is a friend of Class B because A has an instance variable of type B; Class B is a friend of Class C because B has an instance variable of type C; Class C is a friend of Class D because C has an instance variable of type D. As far as I can tell there is only direct friendship.
The reason I'm asking about method names is because if there was an actual program that utilized a structure like this, I think that the names of methods should clearly reflect what each method does. In my example, Class A's doSomething() calls Class B's doSomething(), but it would be silly to have a method named "callClassBsDoSomething" in Class A. However, it would be confusing to just name it "printName" because it doesn't actually print anything and there is already a method in Class D named "printName."
Re: using variables from an imported package
Quote:
Originally Posted by
awinston In my example Class A is a friend of Class B because A has an instance variable of type B; Class B is a friend of Class C because B has an instance variable of type C; Class C is a friend of Class D because C has an instance variable of type D. As far as I can tell there is only direct friendship.
I have to apologize because I misread your previous example; consider most of my previous reply not written; sorry for the confusion. (it's Sunday and I'm extremely lazy today and my brains have a day off ;-)
Quote:
Originally Posted by
awinston The reason I'm asking about method names is because if there was an actual program that utilized a structure like this, I think that the names of methods should clearly reflect what each method does. In my example, Class A's doSomething() calls Class B's doSomething(), but it would be silly to have a method named "callClassBsDoSomething" in Class A. However, it would be confusing to just name it "printName" because it doesn't actually print anything and there is already a method in Class D named "printName."
Different names don't matter for the example; you pick any (sensible) name you like.
kind regards,
Jos
Re: using variables from an imported package
Quote:
The reason I'm asking about method names is because if there was an actual program that utilized a structure like this, I think that the names of methods should clearly reflect what each method does.
Yes
Quote:
In my example, Class A's doSomething() calls Class B's doSomething(), but it would be silly to have a method named "callClassBsDoSomething" in Class A. However, it would be confusing to just name it "printName" because it doesn't actually print anything and there is already a method in Class D named "printName."
One of the points made in the article is that you shouldn't expose implementation details. If I was using your class A I wouldn't care that it was calling B's doSomething() and you needn't commit yourself to implementing its behaviour that way. The name of the method should describe the particular sort of name printing that it does. (these simple examples don't describe what makes these methods different) At least that's the way I think of it - from the POV of A's users - it prints names.
Re: using variables from an imported package
So would it be acceptable to have (in this case) 4 methods named "printName"? Again, I realize that this case is highly abstract and probably unrealistic.
Re: using variables from an imported package
Unfortunately Jos' example was intended to represent a typical arrangement where the details of the something-that-was-done are unimportant. In a more realistic example you may well find that A's name printing does something specialised and that could be reflected in the name - printBName() - where B makes sense in the context of A.
(Say A was a Car class. It might have a printEngineName())
-----
I'm no expert in this stuff (patterns in the broadest sense) - but I *do* know that you can rapidly become confused by generalities. The article that started all this describes some actual code, and if you Google about for the Law of Demeter you will see much more.
If you are really interested it might be a good exercise to flesh out Jos' example. And try to construct examples where a demeter-compliant "delegator" method seems natural, and others where it appears to be a pain in the @ss or an "artifact" that seems odd and contrived. (The author of the article mentions CRC cards. I read about them years ago and don't know if they have any currency. But perhaps they relate to this.)
Re: using variables from an imported package
Quote:
Originally Posted by
pbrockway2 If you are really interested it might be a good exercise to flesh out Jos' example. And try to construct examples where a demeter-compliant "delegator" method seems natural, and others where it appears to be a pain in the @ss or an "artifact" that seems odd and contrived. (The author of the article mentions CRC cards. I read about them years ago and don't know if they have any currency. But perhaps they relate to this.)
If you ignore the LoD the 'C' part of your CRC card (the 'Collabaration' part) becomes full of other classes, i.e. your class is coupled to many other classes. In my example A is coupled to B and C while it only needs to be coupled with B at the expense of that 'artefact' method in class B.
kind regards,
Jos
