dynamic inherence

[itaipee]

I have class called GeneralLine that recive String (line with several fields and build itself using this string
for example - if the constructor get the following strign argument

1 text1 "My name" Itai

then the fields key is set to 1 , field "label is set to "My name" ext..

However - I want to add special feature
if getting this string

12  import 1

then the line 12 imports the properties of another line with key 1
I want to make it subclass - with differnet properites - for example refernce field for the imported GeneralLine and method that update the subclass accordingly.

The problem is - I dont know which type of class it is- until the string is read within the constructor itself.

GeneralLine g1 = new GeneralLine(string1);

What do you advise ?

It is not just state or addtional method that I can solve with simple if-else
some of the major method will be sifferent in the subclass
for example
GeneralLine.getName -> return field name
subclass.getName -> return refernceToImport.getname

[Steve11235]

This calls for a design pattern called a "Factory". A factory class exists only to generate instances of other classes.

So, instead of instantiating your base class directly, you would create a factory class with a method.

static Base newBase(String parm) {
Base instance = null;
// Create the proper class, depending on what is in parm
return instance;
}

Most factory classes require you to instantiate the factory class, but that is only necessary if the factory class itself has to do setup before it can be used. Using a static method makes the factory class much simpler.

[toadaly]

It sounds like Steve has answered you question, but I would add that it is better to have all the options implement a common interface instead of extending a common base class.

[masijade]

It sounds like Steve has answered you question, but I would add that it is better to have all the options implement a common interface instead of extending a common base class.

Not necessarily. If the Classes will be expected to carry out (lets grab a number out of thin air) 20 actions (methods), and 15 of these will have the same implementation details for all (or even just most) of them, then why implement all 20 methods in every Class, when you would, by extending a base/abstract, class only have to implement the 5 that are not the same in the extending classes?

[Steve11235]

I agree with Toadaly and Masijade.

[toadaly]

If the Classes will be expected to carry out (lets grab a number out of thin air) 20 actions (methods), and 15 of these will have the same implementation details for all (or even just most) of them, then why implement all 20 methods in every Class...?

Well sure if that's the case. Interfaces are preferred over extensions when all else is equal, but if all else isn't equal, then it makes no sense to avoid extension.

[masijade]

Well sure if that's the case. Interfaces are preferred over extensions when all else is equal, but if all else isn't equal, then it makes no sense to avoid extension.

Often times, the best solution is to create an interface and an abstract class that implements it, leaving all options open.