Building an interface (even if there's only one implementation) is always right

Re:Building an interface (even if there's only one implement... by hardwaresofton on Wednesday May 25, 2022 @10:45PM (#31513760)

I agree, but not having an interface is a great way to make sure you probably are never able to swap out the implementation (even if someone came along and wanted to do all the work).

Drastic fixes and Rewrites almost always consist of three things:

1. Writing tests to ensure functionality

2. Writing an interface or shimming the existing functionality to redirect control flow

3. Implementing and testing the rewritten functionality/improvements

Obviously you can't do it everywhere, but life is much better when (2) was done up front.

[ Parent | on HN ]

Re:Building an interface (even if there's only one implement... by kjeetgill on Wednesday May 25, 2022 @11:18PM (#31514027)

It depends on a dozen details, but one of the strengths of a language like Java for me atleast is that it's pretty easy it is to do those things fairly bug-free.

One of the biggest dimensions that completely change this conversation is: module boundaries. If you're in a position to touch all of your user's code, it's night and day vs if you're pushing migrations on other teams or God forbid customers.

But if you have all of your code? In Java atleast, it's cake.

[ Parent | on HN ]

Re:Building an interface (even if there's only one implement... by wfrew on Thursday May 26, 2022 @12:43AM (#31514669)

Really you should have those tests upfront. After that noone should be scared of changing any part of the codebase. Let alone 'never' changing stuff.

Releasing rewrites / redesigns behind a feature flag, with a couple of strategic if statements is usually good enough. Noone cares that you had to change code outside of your interface for a release or two.

[ Parent | on HN ]