• Post Reply Bookmark Topic Watch Topic
  • New Topic

Interface forcing constructor signature?  RSS feed

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am building a small library to persist small java Objects. Objects that wants to be persisted must implement an interface (let's say ByteSerializable).
This interface defines a method (public ByteBuffer save()) that will be called when the object needs to be saved, and as per the API contract, must return a 'serialized' version of this object in a bytebuffer.
Now to restore this object, I would like the interface to define a constructor like (public object_name(ByteBuffer )) that will be called when the object needs to be restored from a ByteBuffer. Unfortunately, as far as I know, one cannot influence a class' constructor definition thanks to interfaces.
A function like (public Object restore(ByteBuffer )) would also work if I could make sure that Object is an instance of the class implementing the interface.
Is there any way to force this requirement through interfaces? Or should I just write in the API contract that a object that wants to be persited must also provide a constructor taking a ByteBuffer as argument. (and hope that the users will not forget this..) ?

Any help will be very much appreciated!
Thanks,
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why re-invent the wheel? Why not use ObjectOutputStream/ObjectInputStream and have your classes implement Serializable?
 
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most similar Java APIs work like this: the class has to implement an interface, and it has to have a default constructor. There's no way to enforce the default constructor requirement other than to document it. It's an easy enough thing to describe, and if a class violates the rule, then your API should just fail safe -- i.e., throw a descriptive exception, and return.

Applets work this way, servlets work this way, basically anything that's instantiated based on some description in a text file is designed this way.

The return-value restriction is unnecessary, by the way. Consider this:


[ August 13, 2004: Message edited by: Ernest Friedman-Hill ]
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "I want to force a subtype to have a constructor" (flawed) thought process usually means you want an accessor method.
After all, you can't call constructors on an interface reference, so what would be the point?

Suppose you want all subtypes to have a String argument called 'name' (I assume you have something similar). You cn do this by having a constructor that takes a String argument - but right now, you are designing your interfaces first (like most nice people do ) Instead of thinking "I want to force all subtypes to take a String in the constructor", you could put a method in your interface "String getName()".

Then the clients of the interface can access the name using this method.

I only know what and why you are thinking what you are, because I lecture/tutor Java part-time, and I've seen it numerous times before.

Good luck.
 
Yannick Le Teigner
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all for those helpful information.

Rovas,

I am not using ObjectOutputStream/ObjectInputStream because I want to squeeze the maximum performance possible in my implemantation. Those objects are going to be written on disk, and I believe ObjectOutputStream/ObjectInputStream writes the variable names to the stream, this is something for example that I don't need.


Ernest,

I like this idiom and this is what I will use. It forces me to use reflection, but it is clean.

Tony,

In fact I do not need to access any object's member, I just wanted to force an object to be able to re-construct itself from a ByteBuffer. Calling a constructor with a ByteBuffer as an argument seemed the most logical way, but as I cannot enforce this design I will use Ernest's suggestion.


Thank you again and best regards.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Yannick Le Teigner:


I am not using ObjectOutputStream/ObjectInputStream because I want to squeeze the maximum performance possible in my implementation.


Do note that you can use the Externalizable interface with serialization and take charge of the bit-for-bit byte representation of your objects in the serialized data stream. This can make an enormous difference in performance. Jack Shirazi's "Java Performance Tuning" does some comparative studies of this, and he gets orders-of-magnitude improvements.
 
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:
The "I want to force a subtype to have a constructor" (flawed) thought process usually means you want an accessor method.
After all, you can't call constructors on an interface reference, so what would be the point?


If you know the class name and the parameter list of the constructor, you can call it via reflection.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If you know the class name and the parameter list of the constructor, you can call it via reflection.


You can do a lot of nasty things with reflection (e.g. mute a String).
I think it's important to point out that this suggestion is purely academic and does not belong in production software.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:

I think it's important to point out that this suggestion is purely academic and does not belong in production software.


I beg to differ. Development environments, Java-based scripting languages (*cough*Jess*cough*, BeanShell, presumably Jython), the implementations of RMI, CORBA, and Serialization, and other kinds of tools need to do precisely this, and frequently.

The reflection API is hardly "purely academic;" it's a significant part of what lets Java do what Java does.

Now, does this mean that Yannick ought to use it? Not necessarily yes, not necessarily no. But please don't assert opinions as if they are facts in this forum. Adding "I feel" or "I think" would be fine.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is hardly subjective that calling a constructor via reflection in order to solve what a callback typically solves is not a nice thing to do.

If you wish to argue this fact, then I wish you luck, despite my lack of confidence in your success.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!