public void abstract methodName()

[Matt Kidd]

Okay I'm looking at java.awt.Graphics and there is a method I'd like to use for this exercise I'm doing out of Java the UML way but the method is abstract. Is it a valid method, since there is a definition/explanation for what the method does, or is it an empty abstract method that would need to be overrided in order to use.

I guess my question is can a method be implemented and still be abstract?

[Ernest Friedman-Hill]

Hi Matt,

If a method is abstract, then somebody has to implement it before you can use it. The key thing to note is that you don't really care who. If you're writing (say) paintComponent(), and you get a Graphics object as an argument, then you can go ahead and call that method, and you know that somebody has implemented the method for you!

The big secret here is that the argument won't actually be a java.awt.Graphics object -- it'll be a (say) sun.awt.win32.Graphics object, or some such thing. It'll be a subclass of Graphics which does, in fact, implement that method.

[Matt Kidd]

Originally posted by Ernest Friedman-Hill:
Hi Matt,

If a method is abstract, then somebody has to implement it before you can use it. The key thing to note is that you don't really care who. If you're writing (say) paintComponent(), and you get a Graphics object as an argument, then you can go ahead and call that method, and you know that somebody has implemented the method for you!

The big secret here is that the argument won't actually be a java.awt.Graphics object -- it'll be a (say) sun.awt.win32.Graphics object, or some such thing. It'll be a subclass of Graphics which does, in fact, implement that method.

wow...thats confusing. I'm used to abstract declarations not being implemented until I do it. Why the implicit documentation though? There isn't any mention of how a subclass of Graphics, one that you aren't specifically calling, is the one implementing the method.

[Ernest Friedman-Hill]

There are actually quite a few things like that in the API. It's easy to spot them: abstract classes, of course, but also classes with no public constructors can be like this.

The entire JDBC (Java database) API is made of interfaces, which are similar to abstract classes. Every database vendor provides their own implementation of these classes, each with a different name; but you refer to them just by the interface names, so you don't need to know about. This lets you write database code that works with any database -- just switch to a different driver, and your code doesn't change at all!

[Matt Kidd]

Originally posted by Ernest Friedman-Hill:
(1)There are actually quite a few things like that in the API. It's easy to spot them: abstract classes, of course, but also classes with no public constructors can be like this.

(2)The entire JDBC (Java database) API is made of interfaces, which are similar to abstract classes. Every database vendor provides their own implementation of these classes, each with a different name; but you refer to them just by the interface names, so you don't need to know about. This lets you write database code that works with any database -- just switch to a different driver, and your code doesn't change at all!

1) What are some examples of classes without public constructors?

2) This would be an example of the "program to an interface" principle right? JDBC is about a week away (less if I get my head out of my butt) so I haven't gotten my hands dirty yet but it would seem that is what you're talking about.

[Ernest Friedman-Hill]

1) Well, the first one that pops into my head is the java.util.regex.Pattern class. You only get them from the static Pattern.compile() method. But there are plenty of others.

2) Yes, absolutely. "Programming to interfaces" is exactly what we're talking about.