Creating Model Interfaces for GUI Layer

Question

I'm trying to avoid directly using a class from my model layer in my GUI. But I need to use a method in my class lets say, "setPropertyFoo(object)". So is it worthwhile to create an interface for my class, have my class implement the interface, and then use the interface in my view layer just for this one method? And the broader more general question is, is there a point at which one should not create interfaces? Are interfaces, though a standard of proper OOP programming, ever a symptom of an underlying poor design structure if they are needed in some way? I would hope not but I'm still learning.
// Model layer
public class MyClass implements MyInterface
     private Object foo;
     // For simplicity
     public void setPropertyFoo(Object obj)     
          foo = obj;
public interface MyInterface
     // Just this...Just this one method...
     public void setPropertyFoo(Object obj);
// View layer...
MyInterface face = Factory.createMyClass();
public void valueChanged(ListSelectionEvent event)
     <.....>
     face.setPropertyFoo(list.getSelectedValue());

Answer 1

Your response sounds sensible to me. Thanks.
Part of any piece of software will be about behavior.
Part will be about data. Face it, a lot of what
software does is move data around. IMHO, at boundaries
between layers or modules (e.g. the DTO/DAO/VO for
moving data between a database and your program), or
wherever conversion occurs (to/from XML for instance)
you may need some getters and setters.I agree.
I try to avoid get/set in my code, but if I find I'm
writing a whole bunch of goop just to achieve that
grail, I stop and think about whether concealing that
particular object's state really needs to be
sacrosanct. And when I do provide access to that data,
it's not just blind get/set that sets or returns any
and all fields directly.This is helpful. It makes me think that there may be alternative means of achieving the same end without directly calling "set" on a field. Interesting.
Off the top of my head, if
you're doing a lot of passing objects as parameters to
methods that just call getters and setters and act on
the results, as opposed to saying
object.doSomethingThatModelsABusinessAction().This is helpful too. I think I see what you are saying here.
Using my example in the first post, I could modify it and say...
// View layer...
MyInterface face = Factory.createMyClass();
public void valueChanged(ListSelectionEvent event)
     face.selectionResponse(list.getSelectedValue());
// Then the model class...
Public class MyClass implements MyInterface
     private Object foo;
     // For simplicity
     private void setPropertyFoo(Object obj)     
          foo = obj;
     public void selectionResponse(Object obj)
          setPropertyFoo(obj);
          // At least this gives the object more control
          // over whether or not to set the property at the
          // selection...
}But I also appreciate what you've shared about the danger of the extreme point of view. From just what I've tried, I've been able to determine that it is possible to twist up a simple application and create more design flaws by attempting to eliminate each and every set or get method. So It's reassuring that I can leave some in where it makes sense to do so.