字体,如何扩展它们 [英] Fonts, how to extend them

查看:123
本文介绍了字体,如何扩展它们的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想知道是否有一种方法可以扩展Font类,以便可以通过createFont和deriveFont方法返回自己的Font类.我的意思是这样的...

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").

这样做的原因是为了最大程度地减少最终更改其VM的Java发行版时产生的影响.

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

这是上面召唤的代码:

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

然后在MyFont中,我编写了代码:

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;
}

推荐答案

0th.如果有人想将通用字体传递给您的代码,并且您需要参数作为MyFont的实例,该怎么办?有实际意义吗?您尝试使用继承来调整某些生命周期协议(在这种情况下为对象创建),而这些协议不太适合Java OO范例.请改用工厂方法/原型.

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()不可替代,因为它是静态的.您可以在类中提供自己的版本,但是使用相同的方法名称可能会使您的代码的其他用户感到困惑(以后也是如此).

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).

第二.虽然提供了一些createFont()快捷方式以及deriveFont()可能的新版本,但您也避免避免与您要控制其更改的API链接,因此,鉴于Java实现的变化,您还是必须重新编码/重新编译.正确的避免依赖关系涉及一些反射和用String编码的类名,这些类名会捕获许多ClassNotFound异常以及其他在API更改时可能发生的异常.你不要那样期间.

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.请放轻松,实际上,此代码非常稳定,并且您的应用程序过时并从头开始重写的机会比任何人甚至不赞成使用这些方法的机会都要大得多,更不用说删除它们了.这远远超过了2012年的世界末日(或与宇宙热死无关的任何其他或多或少相关的日期).

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).

要总结一下,只需添加几个易于区分的静态快捷方式:链接到Font.creatFont()的MyFonts.create(),和链接到font.derive(otherArgs)的另一个MyFonts.derive(Font字体,otherargs) .保持简单,简单并密封MyFonts()构造函数,以表明这是工厂/实用程序类.

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.

这篇关于字体,如何扩展它们的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆