> Well, it may involve a bit more work now - which I don't mind doing -
> but adding a new archiver should be easier, as it would not have to do
> the state checking.
>
> The idea is to have the re-usable code in the abstract super-class.
I completly understand your point. But does this bring so m
On 23/04/2009, Christian Grobmeier wrote:
> On Thu, Apr 23, 2009 at 1:49 PM, Torsten Curdt wrote:
> >> Similarly for other methods. The Abstract class would be responsible
> >> for maintaining the current state and checking that the method is
> >> valid for the state.
> >
> > Hm ... sounds a
On Thu, Apr 23, 2009 at 1:49 PM, Torsten Curdt wrote:
>> Similarly for other methods. The Abstract class would be responsible
>> for maintaining the current state and checking that the method is
>> valid for the state.
>
> Hm ... sounds a bit like overkill to me.
for me too.. I had this discussio
> Similarly for other methods. The Abstract class would be responsible
> for maintaining the current state and checking that the method is
> valid for the state.
Hm ... sounds a bit like overkill to me.
cheers
--
Torsten
-
To un
I think it would be possible to enforce the correct sequence of API
calls in the AbstractxxStream classes.
This could be done as follows:
public finish(){
throw Exception if state is invalid
set state to finish
finish0();
}
// Override this if the sub-class needs to do anything.
protected
