@Howard
What exactly is the point of ImmutableValueConversions that seems a very
convaluted way to say XXXBuilder if thats what it is...Why Conversions -
dont most people call this pattern "Builder" ?
For my stuff i have a Builder<B extends Buildable> and Builderable<B extends
Builder> interfaces.
My style is
public class ValueType implements Buildable<ValueTypeBuilder<ValueType>> {
public ValueTypeBuilder builder(){
return ValueTypeBuilder( this );
}
}
public class ValueTypeBuilder implements Builder<ValueType>{
static package private VaueTypeBuilder from( ValueType ){
etc etc
}
public ValueType build(){
// create ValueType here, most properties by this stage especially
scalars have already been validated.
}
}
With a nice base class one can test to make sure that the copy constructor
in the Builder is package private etc and a few other basic things.
On Mon, Mar 14, 2011 at 6:24 PM, hlovatt <[email protected]> wrote:
> I agree with Miroslav's comments that if you choose a good name and
> good class hierarchy then many of the problems go away, his example
> for file/directory paths is a nice one. Below is an extended example
> along the same lines as Miroslav's.
>
> In my own pet project I use the following interface:
>
> public interface ImmutableValueConversions<I, V> {
> I toImmutable() ; // immutable copy or this if already immutable
> V toValue(); // deep copy
> }
>
> To give classes the ability to convert, by copying, back and forward
> between Immutable and Value (mutable) objects, e.g. an Immutable and a
> Value integer pair with a common base interface:
>
> public interface Int {
> int get();
> ... other immutable methods
> }
>
> @Immutable public ImmutableInt implements Int,
> ImmutableValueConversions<ImmutableInt, ValueInt> {
> private final int value;
> public ImmutableInteger( final int value ) { this.value = value; }
> public int get() { return value; } // written by compiler
> public ImmutableInt toImmutable() { return this; }
> public ValueInt toValue() { return new ValueInt( value ); }
> ... hashCode, equals, toString (written by compiler)
> ... other immutable methods, e.g. add
> }
>
> @Value public ImmutableInt implements Int,
> ImmutableValueConversions<ImmutableInt, ValueInt> {
> private int value;
> public ImmutableInteger( final int value ) { this.value = value; }
> public int get() { return value; } // written by compiler
> public ImmutableInt toImmutable() { return new
> ImmutableInt( value ); }
> public ValueInt toValue() { return new ValueInt( value ); } // deep
> copy
> ... hashCode, equals, toString (written by compiler)
> // Mutating methods
> public void set( final int value ) { this.value = value; } //
> written by compiler
> ... other mutating methods, e.g. setAdd
> }
>
> The interface Int is useful to provide a const-view of either an
> ImmutableInt or a MutableInt. EG in Int itself:
>
> Int max( final Int other ) ;
>
> Which can return either an ImmutableInt or a ValueInt (depending on
> which one is the maximum).
>
> This allows me to program primarily using Immutable objects with all
> their advantages, but when required switch to mutable.
>
> -- Howard.
>
> PS Above is a simplification, I am using an extended compiler that
> performs more type checking and understands Immutable and Value as
> types, not annotations (but the above is useable without an extended
> compiler).
>
> On Mar 14, 11:29 am, Miroslav Pokorny <[email protected]>
> wrote:
> > On Mon, Mar 14, 2011 at 2:44 AM, Fabrizio Giudici <
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [email protected]> wrote:
> > > A parallel discussion at the Lombok mailing list revamped some thoughts
> and
> > > doubts about immutability. I'd like have some feedback about it.
> >
> > > Given that immutability is a "turtles all the way down" thing
> ("turtleness"
> > > in the following), a poster raised doubts about things such as File.
> File is
> > > immutable for what concerns its internal state (the path), but all
> methods
> > > that actually work on the related file don't always return the same
> values
> > > (or do the same thing) because they refer to the actual file which is
> > > mutable.
> >
> > > Such a class is regarded as mutable or immutable? Of course, I'm
> interested
> > > in the practical purposes.
> >
> > > Curiously, the "anemic object" antipattern is something that would help
> > > here. If you defined File only as a wrapper on a path, and FileSystem
> > > another class which accepts a File as argument, you would have clearly
> > > separated the mutable and immutable portions.
> >
> > > But I don't like anemic objects. When I can, I just separate the two
> parts
> > > in two different objects, but they stay bound together. Referring to
> some
> > > actual code that I'm not using in production but for some tutorial, I
> have
> > > a:
> >
> > > FileModel fileModel = new FileModel("/foo/bar");
> > > String path = fileModel.getPath();
> > > String name = fileModel.getName();
> >
> > > and the above two methods are the only two specific methods of
> FileModel.
> > > So far, it's anemic and immutable. Going on:
> >
> > > fileModel.as(Removable).remove();
> > > long size = fileModel.as(SizedInBytes).getSize();
> > > List<FileModel> children =
> > > fileModel.as(Composite).findChildren().results();
> >
> > > That as() is my way to deal with DCI and Semantic models. In simple
> words,
> > > it just recovers a "role" of FileModel by referring to its interface -
> > > as(Removable) is a shortcut for as(Removable.class). All the roles in
> the
> > > example above are simple, stateless objects that work on the real
> > > filesystem. Clearly, I've separated behaviours: FileModel on its own
> > > encapsulates the really immutable portion, while roles keep the
> remainder
> > > behaviours. But there's no turtleness in FileModel, because there's
> only a
> > > single level of turtles (i.e., fileModel.as() always returns the same
> thing
> > > for each role, but the returned object is not immutable in the strict
> > > definition).
> >
> > > There are variations on the theme. Some roles are de facto hardwired in
> > > FileModel; others can be dinamically injected by the context. But once
> a
> > > role has been injected into a FileModel instance, it stays forever.
> >
> > > How do you comment about immutableness of FileModel? As said, there's
> no
> > > turtleness. It's enough to say that FileModel is not immutable?
> >
> > > PS Another related question is about equals() and hashCode()... Are two
> > > FileModel instances with the same path, but possibly different roles,
> > > equals()? I'd say not. But this is another question, and more related
> of the
> > > broken definition of equality in Java.
> >
> > Firstly im going to say something a little different. Maybe the problem
> is
> > the naming leads one to have problems grasping w/ what is actually
> > represented and what state is held by FileModel. This of course means
> that
> > FileModel.setLastUpdated() seems like an oxymoron, how can a File which
> > includes a last updated property by immutable and yet the change works
> when
> > the setter is called. For me when i see "Model" i think of a value object
> > that holds exactly what it says and its much nicer for alots of the
> reasons
> > we all know that it is immutable (concurrency, no defensive copying etc).
> > After all valueObjects are an extension or aggregation of the primitives
> > provided by the runtime which themselves are immutable (you cant change
> an
> > int or a long, you can however calculate some new value and replace it).
> > Thus continuing in that spirit value objects should always look immutable
> > and be immutable.
> >
> > After all that maybe the answer is to start w/ a better name, something
> like
> > FileSystemPath and still all the actions hanging off it.
> >
> > FileSystemPath {
> > String name();
> > String path();
> > void setLastUpdated(DateTime ...)
> >
> > }
> >
> > FilePath extends FileSystemPath {
> > InputStream read();
> > OutputStream write();
> > etc...
> >
> > }
> >
> > DirectoryPath extends FileSystemPath {
> > FilePath createFile( String name);
> > etc...
> >
> > }
> >
> > Building on the above, its quite obvious that the object holds the state
> > that it is called after and that it really is immutable. It says its a
> Path
> > thats what it holds. By avoiding the need to call it "File" it is more
> > evident that it is not a "File" but the path to a File and thus all the
> > actions thus hit something else instead of the internal state.
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
mP
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
