StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>This is really appropriate for the <a href="http://en.wikipedia.org/wiki/Flyweight_pattern" rel="noreferrer">Flyweight</a>. That is basically what you are trying to accomplish with the statics. In terms of how to serve the Flyweight object so that you don't create thousands of them, here are some ideas. </p> <p>One is the factory, which you state you thought about and rejected, although you didn't state why (so any other ideas may suffer from the same problem) so I won't go into it.</p> <p>Another is to have the value type have a method which can serve its converter. Something like this:</p> <pre><code> public class ValueType { public static final TextTransformable<ValueType> CONVERT = .... } </code></pre> <p>And then use it like this:</p> <pre><code> ValueType value = ValueType.CONVERT.fromText(text); String text = ValueType.CONVERT.toText(value); </code></pre> <p>Now that doesn't enforce that all ValueType's provide their converters via the same mechanism, for that I think you need a factory of some kind.</p> <p>Edit: I guess I don't know what you find inelegant about a factory, but I think you are focused on callers, so how does this feel to you:</p> <pre><code> ValueType value = getTransformer(ValueType.class).fromText(text); </code></pre> <p>The above can be done with a static import of the factory and a method that has a signature like so:</p> <pre><code> public static <T> TextTransformable<T> getTransformer(Class<T> type) { ... } </code></pre> <p>The code to find the right transformer isn't necessarily the prettiest, but from the callers perspective everything is nicely presented.</p> <p>Edit 2: Thinking about this further, what I see is that you want to control object construction. You can't really do that. In other words, in Java you can't force an implementer to use or not use a factory to create their object. They can always expose a public constructor. I think your problem is that you aren't happy with the mechanisms for enforcing construction. If that understanding is right, then the following pattern may be of use.</p> <p>You create an object with only private constructors which wraps your value type. The object may have a generic type parameter to know what value type it wraps. This object is instantiated with a static factory method which takes a factory interface to create the "real" value object. All framework code that uses the object only takes this object as a parameter. It does not accept the value type directly, and that object cannot be instantiated without a factory for the value type.</p> <p>The problem with this approach is that it is quite restricting. There is only one way to create objects (those supported by the factory interface) and there is limited ability to use the value objects, as the code processing these text elements has limited interaction only through this object.</p> <p>I guess they say there isn't a software problem that can't be solved via an extra layer of indirection, but this may be a bridge too far. At least its food for thought.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload