Member Avatar for Sailor_Jerry

What are the benefits\drawbacks about the design below?

Here is a simple example of the possible class design.
What are the benefits of doing it this way? vs. just dropping the interface class all together.

=================================
Public interface Car
{
public String getColor();

public void setColor();
}

==================================
public class CarImplement implements Car
{

private String color;

public String getColor()
{
return color;
}

public void setColor(String color)
{
this.color = color;
}
}
===================================

thanks

  • 5 Contributors
  • 5 Replies
  • 212 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by proghelper

Dani AI

Generated

Short answer: for a plain getter/setter “bean” an interface is usually overkill. Use an interface when you need a behavioral contract, multiple implementations, or a clear API boundary. As and touched on, the real value of an interface is decoupling callers from concrete implementations so you can swap implementations (or mock them) without changing client code. ’s RMI-era point has historical truth — remote systems sometimes relied on Java interfaces — but modern services often enforce contracts outside the Java type system (REST/gRPC/IDLs).

Why you might add an interface

  • Decouples modules and enables dependency injection and easy mocking in tests.
  • Lets a library export a stable API while changing the implementation behind the scenes.
  • Useful where multiple implementations will exist (different storage engines, test fakes, platform-specific variants).

Why adding an interface for every getter/setter hurts

  • Extra files and indirection with little design gain (YAGNI).
  • More maintenance: every tiny bean change now touches two types.
  • Some frameworks (ORMs, serializers) expect concrete classes; too many tiny interfaces complicate that.
  • For plain data carriers, newer Java features (compact immutable forms) reduce the need for boilerplate interfaces.

A practical pattern (example)

public interface UserRepository {
  Optional<User> findById(int id);
}

public class JdbcUserRepository implements UserRepository { /* JDBC code */ }

public class UserService {
  private final UserRepository repo;
  public UserService(UserRepository repo) { this.repo = repo; }
}

Rules of thumb

  • Use an interface for services, repositories, or public API surfaces.
  • Skip interfaces for internal, simple data holders—use a final class or a record-style type.
  • If you publish a library, expose interfaces/factories and keep implementations package-private.
  • Don’t confuse “interface for every getter” with sound design — prefer meaningful abstractions.

Recommended Answers

All 5 Replies

Member Avatar for yni420

In this case i dont think there is any specific benefit of using interface.
Interfaces are useful when the child classes have same methods which have different implementation.
More than that interfaces are useful when we require multiple inheritance

Member Avatar for alpha_foobar

Interfaces are also typically required when you are writing distributed systems.

Member Avatar for jwenting

uh, not just distributed systems and in distributed systems too it depends on the design of the system :)

The Interface defines your public interface. Handy when you have multiple implementations. Typically you don't want any class using your classes (instead of creating instances of them) to have to care about what actual implementation type they're dealing with so you write those classes against the Interface instead.
You can then send them something else completely as long as it implements that Interface and it'll work.

Member Avatar for Sailor_Jerry

Thanks for you help.

jwenting. I am not 100% clear on your post. But I think i am the right track.

My thinking for creating interface for my getters and setters is to promote maintainability.

I want to do this for all my classes that have the getter and setter logic.
I don’t totally understand the benefits.

jwenting. i think you were saying doing this will give me the flexibility to change the class the implements the interface, without breaking any other code.? :)

Member Avatar for proghelper

Interfaces are placeholders. They ensure the must be implemented subset of methods are implemented by all that uses the interface. Kind of way to ensure a given set of operations are always supported by all who implement the inerface.

----------------------

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.