dcsimg
which design pattern suits for minimal changes to happen when an interface method signature is changed.
2 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   rahul_gutta
Posted On:   Thursday, June 30, 2005 01:25 PM

In our senario we are using an Interface which is implemented by hell number of classes. Sample Code: public interface Test { public void test(long pk_id); } The above defined interface is implemented by, say about 100 classes which has almost same implementations but defers on the information retrieved from database by the argument which is primary key. Now we want to change the method signature to have an object as an argument which has pk_id as its property. Is there any better solution without changing the method signatures in 100 classes. If so please help us out or can anybody help us understand the design fault in the existing application.    More>>

In our senario we are using an Interface which is implemented by hell number of classes.
Sample Code:

public interface Test {
public void test(long pk_id);
}

The above defined interface is implemented by, say about 100 classes which has almost same implementations but defers on the information retrieved from database by the argument which is primary key.

Now we want to change the method signature to have an object as an argument which has pk_id as its property.

Is there any better solution without changing the method signatures in 100 classes. If so please help us out or can anybody help us understand the design fault in the existing application.

   <<Less

Re: which design pattern suits for minimal changes to happen when an interface method signature is changed.

Posted By:   Shaun_Childers  
Posted On:   Tuesday, August 30, 2005 10:05 AM

Another way to handle this is to have an interface that defines your methods you want all objects to implement.


public interface Test {

    public long getId();

}


Define and abstract class that has (aside from a default constructor), a constructor that takes in the value:


public abstract class Master {

    ...

    private long pk_id = -1;

    ...

     public Master(long pk_id) {

         this.pk_id = pk_id;

     }

    ...

    public long getId() {

        return this.pk_id;

    }

}


Now you can see that any (you mentioned 100) class that extends the Master class will have access to the primary key value regardless of how you set it. In other words, if/when you needed to change this, you would simple change the Master constructor to now accept an Object that contains the primary key and the subclasses would still have access to the primary key value without needing to be modified (via the getId() method. For example:


     public Master(Object o) {

         this.pk_id = o.getPK();

     }

Re: which design pattern suits for minimal changes to happen when an interface method signature is changed.

Posted By:   WarnerJan_Veldhuis  
Posted On:   Friday, July 1, 2005 03:31 AM

Well, changing an interface, as you discovered yourself, is generally a bad idea. It's not really a design fault. You can make it easy on yourself, by using an IDE with refactoring options. With IDEA IntelliJ and Borland JBuilder, you can change a signature, then the IDE will make all the necessary changes for you.



One thing you could keep in mind next time when using interfaces is to create one interface, and one abstract class that implements this interface. Then you can let your 100 classes inherit from the abstract class. If all the 100 classes override the test(Object) method from the abstract class you would still have the same problem, but you could make a abstract method that does the actual work:

public interface Test {
public void test(Object pk);
}

public abstract class AbstractTest implements Test {
public void test(Object pk) {
//get some stuff from the database
// pseudo code warning
Object result = myConnection.get(pk);
// now let the implementations do their work:
this.doTest(result);
}

public abstract void doTest(Object thing) ;
}

public class MyTest extends AbstractTest {
public void doTest(Object thing) {
//do the actual work here
}
}

About | Sitemap | Contact