Learn how to deal with objects: creating them, reading their values and changing them, and calling their methods. Also learn how to cast objects from one class to another, cast to and from primitive data types and classes, and take advantage of automatic conversions through autoboxing and unboxing.A Primer for Aspect-Oriented Programming in Java
AOP is not a successor to OOP, but a new way of looking at object functionality: allowing the behavior of an object to be modularized and used across other components. Tim Stevens explains the difference and shows how powerful AOP can be. Perhaps too powerful.
Good to see that my favourite online magazin touches the real hot topics of java programming, things developers argue about for hours in coffee breaks 😉
Please don’t make this one more “Why not language X?” discussion. This never ends up in any conclusion, just flames.
Everyone have their own favorite pet language, if you have nothing to add to the subject of the article, it’s better to just watch (or even better, write a nice, complete article about Forth)
peace
Rodrigo
Good intro to working with objects in Java. Nice reading.
Thanks, Eugenia!
I haven’t been programming a lot in Java, but it’s one of my preferred tools, though.
“Why is Java still used, when FORTH beats it in every respect?”
Why Forth, when APL beats it in every respect?
Seriously, Nice article. Even though the headline was sligthly misleading. It could have mentioned Aspect Oriented programming somewhere. I almost didn’t read it because of this.
By the way, does anybody have any experience with AspectJ and its pros and cons compared to this JBoss thing, or have any hints on the how the aspects best can be integrated into the design and modeling of an application.
the reason my uni chose java is mainly its simple syntax (not that that means I can understand it all the time :-p ) and its cross-platform with no changes (especially true at my level of programing).
The point is they are trying to teach us not to program, but to program well. Java is a modern language that is a good base to build upon. Java apps –> appletts –> servlets then on to watever language you wish to learn
yet, we are all missing the hard core language-geek based analisys of (non)polymorphism of the the new operator.
An IIRC static variables are not class variables… just.. well.. static
An IIRC static variables are not class variables… just.. well.. static
Static variables are class variables. Non-static variables OTOH are what you would call instance variables.
Why is java and c# pushed down our throats ?
The way Sun and Microsoft try to convert universities and businesses is getting to the point of brainwashing.
Not much differs them from RMS or GPL zealots then now does it….
An IIRC static variables are not class variables… just.. well.. static
Static variables are class variables. Non-static variables OTOH are what you would call instance variables.
Get some knowledge before you contradict others. Static variables are not class variables; Java has no class members. If static members were class members, they would behave accordignly with inheritance and polymorphism. They do not. All they have to do with their classes is default scope.
This is a serious design flaw.
This is a serious design flaw.
How is it a design flaw and what makes it serious (serious as in “makes programming difficult”)?
I’m sure, if it was a serious design flaw, it would have had a serious effect on my abilities to succesfully write Java programs. But since I’ve never noticed it I won’t even label it as a flaw.
Just because it is not “your favourite OO language” does not mean it is a worthless piece of crap.
This might look like a design flaw for a lets say Eiffel or SmallTalk programmer. but in real life programming it solves many problems many OO purist struglles. i believe java does a good job committing as much as possible to OO rules (lets say %99). if you want to critisize OOness of languages, C# or C++ is a beter candidate for that.. java has simpler syntax, and more object oriented than those.
The wikipedia definition of class vairable:
The term class variable is used in object-oriented programming to describe a variable that is associated with a class, not with a particular instance of the class.
Now, can you please share some of your infinite knowledge, and explain why Java’s static variables aren’t class variables?
Waiiiiiit… You say C# is less OO than Java? I understand C++ is, but please back yourself up.
This is a serious design flaw.
How is it a design flaw and what makes it serious (serious as in “makes programming difficult”)?
All instances of class A share a given behaviour/property (say an icon or a value or a calculation). Make it static. Now you have classes B and C which should subclass A. But they have some differences in what regards that behaviour. You can’t just override it. Only non-terribly-cumbersome solution? Make the behaviour/property an instance member. All instances will point to exactly the same thing, and it will be held as belonging to an instance when it conceptually belongs to the class. Not tidy at all, wasteful if many small objects are involved, and makes programming more difficult.
The annoying part is that it would have been just as easy to have real class members.
This sort of thing is my main gripe with Java – they way it needlessly complicates things. But I’ll have it over C/C++ everyday.
The term class variable is used in object-oriented programming to describe a variable that is associated with a class, not with a particular instance of the class.
Now, can you please share some of your infinite knowledge, and explain why Java’s static variables aren’t class variables?
Short answer (as the 2 posters before you understood): because Java static variables aren’t associated with a class. They are accessible to/through it, which is only part of being associated to it. If you have
class A { static Object something(){ return null; } }
you can’t override it in
class B extends A { static Object something(){ return B_something(); } }
as you would be able to with an instance method – if you call
((A)(new B())).something() you’ll get null and not B_something().
Obviously, since method pointers are stored in the class, this problem affects variables more than it does methods (you just have to make the method an instance method and then you can use it as a class method while you couldn’t if it were static – you need an instance though, which can be ugly though simple to code).
This point should be one of the first to be explored when teaching Java.
There are several reasons that Java is becoming the standard programming language for teaching:
1. It’s free (as in beer.)
2. It has an enourmous toolkit that is portable across all supported platforms.
3. It protects students from unecessary complications such as segmentation faults, pointer arithmetic, heap allocation, etc.
4. OO design is all the rage at university.
Personally, I think that the portable toolkit is the most powerful argument. It allows students to make interesting, interactive programs almost right from the start. Back when C was the language of choice, every school/prof had their own favorite toolkit. This was usually chosen for its value as a teaching tool (i.e. either very primitive or very non-portable – sometimes both.)
class A { static Object something(){ return null; } }
you can’t override it in
class B extends A { static Object something(){ return B_something(); } }
as you would be able to with an instance method – if you call
((A)(new B())).something() you’ll get null and not B_something().
Classes are static entities (as long as one ignores reflection anyway). If you want dynamic dispatch, you have to instantiate them and get run-time objects.
Static methods should be accessed through the class name (A.something()), not through an object reference.
I’m puzzled as to why the Java designers ever allowed calling a static method through an object reference. It just confuses people.
So, polymorphism is a requirement for a static variable/method to also be a instance variable/method. That’s interesting… It doesn’t fit any definition I’ve ever come across, though. I guess we’ll just have to agree to disagree
Anyone up for a “java is slow” flamefest?
Classes are static entities (as long as one ignores reflection anyway). If you want dynamic dispatch, you have to instantiate them and get run-time objects.
First, classes are static in Java, not in major OO languages. Second, it hasn’t to do with being dynamic. Suppose I have class Car with a method to retrieve some instances:
Car[] Car.carsWith(String property);
Then I have subclasses Ford and Toyota. In both, the implementation must differ, for some reason. I can’t use Car.carsWith(), nor can I write Ford.carsWith() or Toyota.carsWith().
Howsoever anyone may claim this is good (??) or that it’s no big deal, the fact is that it shows java’s static members aren’t class members.
Want a simpler one? Suppose you have static String brandOrigin in Car class. Set to null or whatever. You then have each subclass fill brandName with the correct value. Class Ford has brandOrigin=”US”, class Toyota has brandOrigin=”Japan”, etc. You then can be assured that whenever you have an unspecified car, you can count on myCar.brandOrigin to give you it. Right? Wrong. It’s the same problem as above, but maybe more understandable.
For literals, you can reasonably write an instance method brandOrigin() which will return the right value according to the class. That’s acceptable because 1) methods are stored only once and 2) literals require no external resources.
But what if it’s brandLogo you want? Will you load the image each time it’s called? No. Will you cache it in the object? Then it’s one image for each object! Will you cache it in the class? Other than through some boring hack you can’t.
Static methods should be accessed through the class name (A.something()), not through an object reference.
If it’s an object you’ve got, it’s probably to it that you refer.
There are 3 possible kinds of members:
. Instance members
. Class members
. Utility members
It’s the latter that it’s most ugly to access through an object reference, especially because when java’s static members are really doing the part of a class member hardly anyone would think of not accessing them through the class name.
I’m puzzled as to why the Java designers ever allowed calling a static method through an object reference. It just confuses people.
In Smalltalk you just can’t (you have to write the equivalent of object.class().method()). But Java chose to go the way of C++, and that seemed to imply procedural heart with an OO front-end, vm and gc.
So, polymorphism is a requirement for a static variable/method to also be a instance variable/method.
I’m puzzled as to what the above means. For a variable to be a class variable, it must accord to OO. OO implies ihneritance and polymorphism. Java’s static members are made accessible to rather than inherited by subclasses.
That’s why java’s static members are called ‘static’ and not ‘class’. Not because the word ‘class’ was already taken.
Never mind the zillion utility methods that have become attached to a ‘class’ like Arrays.this() and Arrays.that(). Arrays isn’t a class in any OO sense. What does that make of its static members?
Anyway, the whole point here is someone pointed out that it was incorrect use of terminology to call ‘class variables’ to java’s static variables. That someone obviously knew the difference, but had to be ‘corrected’ by someone who didin’t, lest anyone would think java has some defect. I suggest a march to Sun’s headquarters demanding that static be replaced with ‘classy’… they’re the culprits! They called them things static!
Anyone up for a “java is slow” flamefest?
It is. So what? No one seems to have brought that issue up.
Everything is slow nowadays, either way…
Amazing that a technical remark on Java is taken for an attack.
I’m puzzled as to what the above means
I’m a bit puzzled about that too… Substitute “instance” with “class” and it should make more sense.
For a variable to be a class variable, it must accord to OO. OO implies ihneritance and polymorphism.
Well, I would say that OO implies classes and objects. Inheritance and polymorphism are great features, but they don’t define “Object oriented”.
Amazing that a technical remark on Java is taken for an attack.
It was never taken as an attack, and my reply was never meant as a defence. Judging by the length and tone of your replies, you seem to feel a lot stronger about this than me.
BTW: I don’t think java is flawless and I _really_ would like to have polymorphic static variables in java.