Bernd Eilers suggested a interfaces based approach to handle Style information in odf4j:
My approach would be to use something like the following which is almost
completely interface based and hides the real implementation classes as
inner class of a factory making it unavailable for the API to construct
objects without using their factory. Also I would not want to have a
generic Object getProperty(String name) and expose static String
constants for attribute names or something like this as I consider the
list of things to get/set fixed by the specification and thus we only
need specific getter and setter methods and nothing generic. I would
also like to suggest to derive specific Styles from a common base Style
interface for each different Style family.
public interface Style {
public String getDisplayName();
public String getStyleFamily();
...
public Style getParentStyle()
}
public interface SectionStyle extends Style {
public String getBackgroundColor();
public StyleBackgroundImage getBackgroundImage();
...
}
public interface TextStyle extends Style {
}
// note this is a little bit special because ParagraphStyles
// contain the same things as TextStyles plus some more
// and so we can inherit here
public interface ParagraphStyle extends TextStyle {
public int getBackgroundTransperancy();
...
}
// special stuff eg. for subelements of styles gets
// into own interfaces, for example
public interface StyleBackgroundImage {
public static final String REPEAT_NO="no-repeat";
...
public String getRepeat();
public void setRepeat(String newRepeat);
..
}
and now in Style Factory have an abstract implementation base class as
inner class plus implementation classes derived from it as inner classes
public class StyleFactory {
public final abstract class StyleImpl implements Style {
// constructor
public StyleImpl(Node node)
}
public final class TextStyleImpl extends StyleImpl implements
TextStyle {
...
}
public final class ParagraphStyleImpl extends TextStyleImpl
implements ParagraphStyle {
...
}
}Would like to suggest to do the similar thing than with existing classes
like Element and ElementFactory that is to convert Element, BlockElement
etc to interfaces and have ElementImpl, BlockElementImpl etc. as inner
classes inside the ElementFactory class implement them.
Forgot to mention one main reason why to use that more interface centric
approach with inner classes for implementation.
Later on when we move forward this APIU can be expressed in UNO IDL
while classes with constructors that have java specific org.w3c.dom.Node
elements as arguments can not as easily expressed in UNO IDL.
