Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
Jul 10, 2015 at 13:19