Re: Instantiating an abstract class

[m....@4flow.de]

Hi,

of course you can not instantantiate a class with abstract methods.
You can and should provide a constructor, however.

Cheers
	Markus
> Von: Stephen Colebourne [mailto:scolebourne@eurobell.co.uk]
> Gesendet: Freitag, 29. März 2002 19:20
> An: bcel-user@jakarta.apache.org
> Betreff: Instantiating an abstract class
> 
> 
> Hi,
> I would like to be able to define a class as abstract so I 
> only have to
> define the method signatures. (BCEL would then be used to generate the
> implementations). However, I would also like to be able to 
> instantiate the
> class using the standard new operator (This must work in a 
> standard IDE,
> like Eclipse). From what I have seen so far its impossible (I 
> will have to
> use a factory), but have I missed something? Any other bright ideas?
> 
> Stephen
> 
> 
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 

Re: Instantiating an abstract class

[Juozas Baliuka <ba...@mwm.lt>]

----- Original Message -----
From: "Stephen Colebourne" <sc...@eurobell.co.uk>
To: "BCEL Users List" <bc...@jakarta.apache.org>
Sent: Wednesday, April 03, 2002 12:58 AM
Subject: Re: Instantiating an abstract class


> > of course you can not instantantiate a class with abstract methods.
> > You can and should provide a constructor, however.
> >
> > Cheers
> > Markus
>
> > I think it is nothing bad to use factory, and in the most cases it is
> > better.
> >  Factory design pattern very useful for refactoring, in situation like
you
> > have desktop application and need to make it distributed. Change
> > factory method and it become distributed or persistent.
> > I use factory then possible.
> > Juozas
>
> Thanks for the responses.
> The question was prompted by an attept to try to create JavaBeans where
only
> the signatures of the get and set methods had to be written. The answer is
> what I expected, so I will be two choices left to create an abstract
Person:
> 1) Use a factory - Person p = Person.create();
> 2) Use a naming pattern - Person p = new PersonImpl()
> The first one would rely on creating a subclass on the fly, an ideal
> candidate for Juozas's simplestore Enhancer.
> The second one would rely on a classloader creating PersonImpl on the fly,
> which I believe BCEL can do as well.
>
> Thanks
> Stephen

It looks good :
 2) Use a naming pattern - Person p = new PersonImpl()
But if you don't have PersonImpl at compile time, it will not compile.
In this case you must use some "dummy" implementation for Person if it is
abstract.
This will work Person p = new Person(); if class is not abstract and you can
transform
it to implement some "Transparent" aspect for it.


>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Instantiating an abstract class

[Stephen Colebourne <sc...@eurobell.co.uk>]

> of course you can not instantantiate a class with abstract methods.
> You can and should provide a constructor, however.
>
> Cheers
> Markus

> I think it is nothing bad to use factory, and in the most cases it is
> better.
>  Factory design pattern very useful for refactoring, in situation like you
> have desktop application and need to make it distributed. Change
> factory method and it become distributed or persistent.
> I use factory then possible.
> Juozas

Thanks for the responses.
The question was prompted by an attept to try to create JavaBeans where only
the signatures of the get and set methods had to be written. The answer is
what I expected, so I will be two choices left to create an abstract Person:
1) Use a factory - Person p = Person.create();
2) Use a naming pattern - Person p = new PersonImpl()
The first one would rely on creating a subclass on the fly, an ideal
candidate for Juozas's simplestore Enhancer.
The second one would rely on a classloader creating PersonImpl on the fly,
which I believe BCEL can do as well.

Thanks
Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Instantiating an abstract class

[Juozas Baliuka <ba...@mwm.lt>]

Hi,

of course you can not instantantiate a class with abstract methods.
You can and should provide a constructor, however.

Cheers
Markus
> Von: Stephen Colebourne [mailto:scolebourne@eurobell.co.uk]
> Gesendet: Freitag, 29. März 2002 19:20
> An: bcel-user@jakarta.apache.org
> Betreff: Instantiating an abstract class
>
>
> Hi,
> I would like to be able to define a class as abstract so I
> only have to
> define the method signatures. (BCEL would then be used to generate the
> implementations). However, I would also like to be able to
> instantiate the
> class using the standard new operator (This must work in a
> standard IDE,
> like Eclipse). From what I have seen so far its impossible (I
> will have to
> use a factory), but have I missed something? Any other bright ideas?
Hi,

I think it is nothing bad to use factory, and in the most cases it is
better.
 Factory design pattern very useful for refactoring, in situation like you
have desktop application and need to make it distributed. Change
factory method and it become distributed or persistent.
I use factory then possible.


You can review code from simplestore and add it to BCEL utils. I think this
code is more useful
in BCEL project,  not for persistence framework. It is some kind of
alternatyve for standard Proxy
generator, but it can extend user defined class, implement abstract methods
or override super methods.
this code is in commons-sandbox/simplestore  tools package.
It can define class in any classloader and it is no problems to use it in
IDE.



>
> Stephen
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>