Interface Method with Interface Parameter

[Edward.Shtern]

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?

 

[Owen Jacobson]

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?

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

 

[Daniel Pitts]

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

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"

 

[Edward.Shtern]

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

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.

 

[timjowers]

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?

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