2

I've separated interfaces from their implementations by different packages, it's just add clarity, the separation is good looking and it is easier to navigate the project structure. I like it. The only point which confuses me - I've started thinking I might overdo stuff. So the question is - do you think it's a good practice to split code like that?

enter image description here

Eugene
  • 708
  • 5
  • 12

1 Answers1

2

I think it is fine, and I do it.

However I would flip it from how you are doing it, the *impl on every class would drive me insane. Instead I would name the interfaces differently (IThing as I am .Net type) and have them in an Interfaces folder. Then the concrete class (Thing) is 'normal' and would not need to live in a concrete class folder, just wherever made sense.

In some cases I then publish the interfaces folder as a Contracts package for other things that want to work with my main types.

Froome
  • 808
  • 6
  • 11
  • I actually prefer IThing too, but you may want to consider the consistency tradeoffs. Often, I change my coding style a little bit to keep things looking similar to other programming in my current language, and it may be difficult to avoid seeing other "Foo, FooImpl"s in imported Java code. – Katana314 Jul 10 '15 at 13:19