Fonts, how to extend them

Question

I was wondering if there is a way for extending Font class in a manner that I could return my own Font class by createFont and deriveFont methods. I mean something like this...

public class MyFont extends Font {

    // Constructor
    public MyFont (...) {
        super(...);
    }

    // createFont method
    public static MyFont createFont (...) {
        // body
    }

    // deriveFont method
    public static MyFont deriveFont (...) {
        // body
    }
}

I've tryied but I could not retrieve any font, and when doing it the font I got was the default one (I mean "Dialog").

The reason for doing is is to minimize the impact produced by an eventual change in later Java distributions of its VM.

This is the code summoned above:

MyFont onePoint=MyFont.createFont(MyFont.TRUETYPE_FONT,fontStream, size);

Then in MyFont, I coded:

public static MyFont createFont (int i, InputStream io, int size) throws FontFormatException, IOException { 
    Font font = Font.createFont(i, io); 
    MyFont kfont = new
        MyFont(font.getName(),font.getStyle(),font.getSize()); 
    return kfont;
}

What do you mean by "could not retrieve any font"? Please give an example of how you're using your class. — Oliver Charlesworth, Feb 08 '11 at 14:53
@Andres: in my opinion you should not extend `Font` at all. I see no reason to do that just to add a simple utility method. Just add that utility method to some `FontUtil` class of yours and don't try to extend `Font`. — Joachim Sauer, Feb 08 '11 at 15:20
"The reason for doing is is to minimize the impact produced by an eventual change in later Java distributions of its VM." <-- This doesn't make any sense! What sort of changes are you expecting that will break backward compatibility? — Oliver Charlesworth, Feb 08 '11 at 15:21
I mean, If I do the same I've coded above retrieving Font and not MyFont, things go alright, the issues come when trying to wrap Font class. — , Feb 08 '11 at 15:24
Oli, answering to your KIND-MANNERED question, I don't see any possible change, you are right, but I've got asked to do that. — , Feb 08 '11 at 15:28

score 0 · Accepted Answer · answered Feb 27 '11 at 07:51

0th. What if someone wants to pass generic Font to your code, and you require argument being instance of MyFont. Does it make any practical sense? You try to use inheritance to adjust some lifecycle protocols (object creation in this case) which does not fit well into Java OO-paradigm. Use a factory method/prototype instead.

1st. createFont() is not overridable as it's static. You may provide your own version in your class, but using the same method name may confuse other users of your code (and, later on, you too).

2nd. while providing some shortcuts to createFont() and possible new versions of deriveFont() you don't avoid linking against the API you want to control changes of, so you'd have to recode/recompile anyway, given java implementations change. Proper dependency avoidance involves some reflection and String-coded class names with catching lots of ClassNotFound exceptions and other whatnot which may happen on an API change. You don't want that. Period.

3rd. just relax, really, this code is quite stable and chances your app gets outdated and rewritten from scratch are much greater than anyone even deprecates those methods, leave alone removing them. this is well beyond the end of world in 2012 (or any other more or less relevant date closer than heat death of the universe).

To wrap it up, just add couple of easily distinguishable static shortcuts: MyFonts.create() chained to the Font.creatFont(), and another MyFonts.derive(Font font, otherargs) chained to font.derive(otherArgs). Keep it simple, dude, and seal the MyFonts() constructor, to indicate this is a factory/utility class.

Fonts, how to extend them

1 Answers1

Linked