Interface Method with Interface Parameter

Thread view:

Edward.Shtern@gmail.com - 01 Nov 2007 22:24 GMT

I must be breaking some rule of Object-Oriented Programming, but I
can't figure out how else to do it.

I have an interface, let's call it Formatter();

public interface Formatter {
public void format(Item item);
}

pretty self explanantory.

Problem is that I want Item itself to be an interface because
implementors of Formatter will want to deal with their more specific
types if Item's. So I am forced to classcast to those more specific
types of Item's in the implementing classes of Formatter, which sends
up a red flag to me.

How else can I do this?

Reply to this Message

Owen Jacobson - 01 Nov 2007 22:49 GMT

On Nov 1, 2:24 pm, Edward.Sht...@gmail.com wrote:

> I must be breaking some rule of Object-Oriented Programming, but I
> can't figure out how else to do it.
[quoted text clipped - 15 lines]
>
> How else can I do this?

Generics might help here:

public interface Formatter<T> {
public void format (T value);
}

However, I suspect you have a deeper design problem that this will
merely move around. Do you actually need all formatters for distinct,
non-overlapping value types to share a common interface? Why? Expand
a bit on how you're planning on using this and maybe there's a better
way :)

-O

Reply to this Message

Daniel Pitts - 02 Nov 2007 02:19 GMT

> On Nov 1, 2:24 pm, Edward.Sht...@gmail.com wrote:
>> I must be breaking some rule of Object-Oriented Programming, but I
[quoted text clipped - 30 lines]
>
> -O

I agree, Generics should help with the current design, but what is your
goal*? Can you just put a "format" method on the Item interface?

* Goal as defined by "I want to provide X for the end user"

Signature

Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Reply to this Message

Edward.Shtern@gmail.com - 02 Nov 2007 13:36 GMT

> On Nov 1, 2:24 pm, Edward.Sht...@gmail.com wrote:
>
[quoted text clipped - 32 lines]
>
> -O

Basically, the Formatter interface is the way for a batch process to
format its output. At compile time the batch process doesn't
necessarily know which Formatter class it'll use, it's relying on a
factory-type setup to retrieve the correct Formatter, depending on the
customer who it's for. The batch process just needs to be able to
call Formatter.format(Item), and ensure that the products of the batch
process output conform to Item's interface.

Reply to this Message

timjowers - 02 Nov 2007 18:36 GMT

On Nov 1, 5:24 pm, Edward.Sht...@gmail.com wrote:

> I must be breaking some rule of Object-Oriented Programming, but I
> can't figure out how else to do it.
[quoted text clipped - 15 lines]
>
> How else can I do this?

No red flag. Good design. Your design says any formatter must take an
Item. The Item could be further specialized for sure. Isn't that what
you want?

The Strategy Pattern in GoF's "Design Patterns" uses inheritance but
nothing wrong with using an Interface either. IF, Grand's "Patterns in
Java" volume 1 uses interface for the Strategy Pattern.

Best,
TimJowers

Reply to this Message

Interface Method with Interface Parameter

Free Magazines