Re: a java design question

From: Oscar kind (oscar_at_danwa.net)
Date: 10/20/04 

Date: Wed, 20 Oct 2004 21:18:46 +0200

Rajarshi Guha <rajarshi@presidency.com> wrote:
> I have a problem whose solution I'm not sure of:
>
> I have a set of functions all of which return an object of some class
> (say A). Furthermore I want each function to implement a few specific
> methods (say, m1, m2). This way I can allow other people to easily add
> functions as long as they implement the interface and so I dont have to
> change anything else.

If I read "function" to mean "class", it makes sense. I'll do that for
now, but please be more precise in the future. It's easier (for others).

> My design involved the declaration of the class A
>
> public class A {
> int a;
> int b;
>
> A() {
> }
>
> A(int x) {
> }
> }
>
> and an interface
>
> public interface FunctionInterface {
> A m1(int x, int y);
> void m2(String x);
> }
>
> The I go onto create the functions themselves as classes:
>
> public class f1 implements FunctionInterface {
> A m1(int x, int y) {
> // do something
> }
>
> void m2(String x) {
> // do something
> }
> }
>
> and so on for functions f2, f3 etc. Finally in my actual program I would
> do:
>
> f1 f1object = new f1();
> f1.m1(1,2)
>
> etc.
>
> My question is: is this a good way to design such a system. In the end
> these functions will belong to a package. Al I want to ensure is that each
> function implements the described methods and that other people can add
> functions which can simply be dropped into the package heirarchy.

Yes, it's a good design; assuming you document the interface well to
describe the behaviour of the methods. It allows an implementer complete
freedom of inheritance while still specifying the methods you want them to
implement.

It's called the "strategy" design pattern.

> I feel uneasy with having to make the function classes resulting in my
> having to instantiate them and then call the required method.

Don't: instantiating objects is not that expensive.

> Is there another way to do this: say, by making a class whose methods
> would be the actual functions? But then it seems that if somebody wanted
> to add a function they would have to fiddle with the class (to add the
> declaration of the new function).

Not cleanly. Besides, using known design patterns enhances the
maintainability of your code. For more design patterns, see:
        http://home.earthlink.net/~huston2/dp/patterns.html 

-- 
Oscar Kind                                    http://home.hccnet.nl/okind/
Software Developer                    for contact information, see website
PGP Key fingerprint:    91F3 6C72 F465 5E98 C246  61D9 2C32 8E24 097B B4E2

Relevant Pages

  • Re: Class inheritence & subclassing
    ... Provides a common interface for accessing containers and objects. ... The Design Patterns book is a must-have for OO developers - problem is ... ' IColoredComponent ... Public ReadOnly Property Color() As System.Drawing.Color Implements ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Basic Concept Question Why Interface?
    ... The answer can be found by digging deeper into Design Patterns. ... Nearly every one of these design patterns REQUIRES the use of interface ... definitions in order to create the concept of a contract where any object ... > void PostInterest(); ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Program to an Interface not an implemetation
    ... >I am looking at the Gang of Four ... > an Interface, not an implementation'. ... book like "Design Patterns Explained" by Shalloway. ... I do not answer questions on behalf of my employer. ...
    (comp.object)
  • Re: Why Java interface?
    ... i recommend books related to 'Design Patterns' to you. ... in java, 'interface' is _only_ way for multi-inheritance. ... But in an interface, there are> only abstract methods, and we have implement all the methods in the> class that implements this interface, why do we still use interface? ...
    (comp.lang.java.programmer)