Might I point out items 1 and 2 in Effective Java?
On 16 June 2014 11:14, Gary Gregory <[email protected]> wrote: > On Mon, Jun 16, 2014 at 12:04 PM, Remko Popma <[email protected]> > wrote: > >> >> On 2014/06/17, at 0:40, Ralph Goers <[email protected]> wrote: >> >> From the Map perspective it may not be better. But from the perspective >> of abstracting how individual Plugins are created it probably is better. >> Remember, this is for allowing some sort of programmatic configuration, >> such as a configuration file written in Groovy. I find the idea of that >> kind of configuration actually creating Appenders, Layouts, etc, directly >> very scary. >> >> >> For programmatic configuration, why wouldn't you just call a constructor? >> > > Because the ctor is private and the factory method is public? > > Gary > > >> >> >> Ralph >> >> On Jun 16, 2014, at 8:36 AM, Remko Popma <[email protected]> wrote: >> >> >> >> On Tuesday, June 17, 2014, Ralph Goers <[email protected]> >> wrote: >> >>> Yes, for a programmatic configuration builders would be better. Unless, >>> of course, we came up with some other way for programmatic configurations >>> to interact with plugins. For example, a method like >>> >>> T createPlugin(PluginType type, Map<String, Object> map) >>> >>> might make more sense. Then it wouldn’t much matter whether we are >>> using builders or the factory pattern. >>> >> >> Is that really better? Personally I try to avoid map-like APIs as it puts >> the burden on the user to know what keys to use and what value types are >> acceptable. >> >> Plus you lose the compiler-check benefits of the factory pattern. >> >>> >>> Ralph >>> >>> On Jun 16, 2014, at 8:12 AM, Matt Sicker <[email protected]> wrote: >>> >>> Programmatic configuration is feature in that list of issues Ralph >>> mentioned. I don't see any good way to do that without using the fluent >>> builder pattern as that's how programmatic configuration APIs are usually >>> done. The other ways are usually things like closures/lambdas, but that >>> would require Java 1.8+ to work. Groovy supports closures which is what >>> makes Gradle so much less verbose, so that, too, is an alternative way to >>> support builders. >>> >>> I guess the important thing to consider here is that the builders aren't >>> for _plugins_, but are for plugin _configurations_. That makes me think >>> that the factory methods (whether they be private or public) should be far >>> more generic such as accepting a PluginConfiguration object (each specific >>> to the plugin) or a generic Map<String, Object> that also makes it a lot >>> simpler to pass in plugin attributes. >>> >>> >>> On 16 June 2014 10:05, Gary Gregory <[email protected]> wrote: >>> >>> Right, so they are not part of the public API, unless we consider >>> programmatic configuration (not from a file). >>> >>> Gary >>> >>> >>> On Mon, Jun 16, 2014 at 10:56 AM, Remko Popma <[email protected]> >>> wrote: >>> >>> Paul this is about the plugin factory methods that are called by the >>> PluginManager to turn a configuration text file into an object hierarchy >>> with Loggers, Appenders, etc. >>> It would be very rare for client code to call these methods directly. >>> Which is why they are primarily called from JUnit tests. >>> >>> >>> On Mon, Jun 16, 2014 at 11:45 PM, Paul Benedict <[email protected]> >>> wrote: >>> >>> If this API is primarily for unit tests, then I don't care as much. I >>> thought this was Public API. When it comes to Public API, I prefer to make >>> it as friendly-to-read and maintainable as possible. >>> >>> >>> Cheers, >>> Paul >>> >>> >>> On Mon, Jun 16, 2014 at 9:42 AM, Remko Popma <[email protected]> >>> wrote: >>> >>> About the validation, wasn't the argument that some of the current JUnit >>> tests look like this? >>> FileAppender.createAppender("true", "true", "true", "true", "true", >>> "true", "true", "4096", null, null, "false", null, null); >>> >>> So, null is fine here for at least four arguments. >>> So it is definitely possible to forget to call the >>> builder.setValue(value) method for those arguments >>> - which is fine if your intention was to set null, but not if you >>> forgot to set some non-null value. >>> >>> The compiler validates that you have the right number of arguments for >>> free. >>> It is not possible for builders to provide the same guarantee unless all >>> arguments must be non-null. >>> >>> About the readability - and as Ralph pointed out this is readability in >>> JUnit code primarily - there are a number of ways to accomplish that. >>> >>> >>> >>> On Mon, Jun 16, 2014 at 11:27 PM, Ralph Goers < >>> [email protected]> wrote: >>> >>> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker <[email protected]>
