----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "BCEL Users List" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
