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?
-
1possible duplicate of Do I need to use an interface when only one class will ever implement it?– gnatJul 10, 2015 at 12:27
-
1@gnat I doubt those two questions have something in common– EugeneJul 10, 2015 at 12:28
-
1How are they different?– PanzercrisisJul 10, 2015 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.– EugeneJul 10, 2015 at 12:45
-
1@Panzercrisis it's evident I wasn't clear with my question, I tried to rephrase it.– EugeneJul 10, 2015 at 12:50
1 Answer
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. Jul 10, 2015 at 13:19