A possible approach to Style Handling using Java Beans

I shall make an effort to explain how we could possibly work with
Styles using Java Beans.

I understand, the entry point for retrieving the style information for
an element, is the <text:style-name > using which we dig down further
in the “content.xml” <office:automatic-styles>.

What we can do here is that for each element’s style information we
have an associated Java Bean with properly defined properties to
reflect the style information. Being a Java bean we automatically have
getter/setter methods for the style information for each element. This
Java bean will be created automatically when the user makes a call to
get/set the style information methods from the API.

Interfaces based approach to Style Handling

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.