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

  • 1
  • 1
    @gnat I doubt those two questions have something in common – Eugene Jul 10 '15 at 12:28
  • 1
    How are they different? – Panzercrisis Jul 10 '15 at 12:41
  • 1
    @Panzercrisis this one is about project structure, it's not like I'm asking if I need to have those interfaces, of course, I need them. The one gnat pointed to is about a creation of an interface if you have only one implementation. – Eugene Jul 10 '15 at 12:45
  • 1
    @Panzercrisis it's evident I wasn't clear with my question, I tried to rephrase it. – Eugene Jul 10 '15 at 12:50
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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.