On Fri, Sep 18, 2009 at 10:21 PM, Greg Brown <[email protected]> wrote: >> many classes are "polluted" by properties and view/model interaction, and >> view styles are also APIs, even though the methods are intended to be >> hidden. This is the nature of the "accepted approach" and perhaps not too >> much can be done about it. > > I'm not sure exactly what you mean by "polluted" - can you clarify? I > actually think the APIs are very clear, especially now that we have been > over them 2 or 3 times.
:-) I am a bit of API zealot, so I don't expect you to agree with me, and I don't know where to start. To sample the obvious, Component has for instance the following methods; public Point mapPointFromAncestor(Container ancestor, int x, int y) public Point mapPointToAncestor(Container ancestor, int x, int y) public Display getDisplay() public Graphics2D getGraphics() I can't for a second figure out why these are 'public' and should probably be 'protected'. There is a method public Skin getSkin() Is it part of the API (or not) that I call getSkin(), cast it to the implementation and invokes methods on it directly? If not, it shouldn't be public. If it is, you just added all the public methods of all the view classes to be part of the API. All containers have a method; public final int add(Component component) yet, many containers are not using it as its primary populator, off my head I recall Accordion.getPanels().add() or something like that. If only a small number of Containers are actually using the add(), it should exist at that level, IMHO. Then there is stuff I am less sure about; Component.validate() sounds like an internal method between a Container and its children. Component.paint( Graphics2D graphics ) --> same thing. Component.getAttributes() --> is 'protected' but none of the existing sub-components calls it. Instead it is called from 'package private' visibility of Accordion, TabPane, TablePane and Form. So that is indication that scope visibility is incorrect (I could not have implemented Accordion outside the package). Also, Attributes sound like something that should be properly typed and not a 'guess my type' Object. And this is just scratching on the surface. A lot of the issues could have been solved with using interfaces instead of classes, where the implementation details in the class can cast to its known types for access. Some issues should perhaps be solved via an injection mechanism. So, nah, you won't get an A for API Design... ;-) Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
