5 ms·

There are good reasons to use interfaces and to just accept the extra minor bit of work that goes with them. When using injection frameworks (like Spring), it m

There are good reasons to use interfaces and to just accept the extra minor bit of work that goes with them. When using injection frameworks (like Spring), it makes life easier to reference an iface and have your concrete class plugged in automagically (using annotations). The iface also provides a clean look at the intentions of the application. Writing impl classes is trivial with an IDE - you can create your impl and fill in stub methods quite easily. The tradeoff of separation can be worthwhile in a complex system.

jbooth 17y ago
Yes, but generally speaking, if you're writing FooIFace and FooImpl you should probably rethink what you're doing.
- jfager 17y ago
  Ideally, you'd just get it right the first time, but if you're going to screw up, it's usually better to screw up by having an interface you don't really need than by having a class that should really be an interface. Generalizing that makes it hard for me to agree that FooIFace and FooImpl is, on its own, evidence that something's wrong.
  - Tuna-Fish 17y ago
    This does condense what I dislike about java quite nicely. All proper java code is full of speculative architecture and genericity -- in order to have your code easily extensible, you do have to have setters, getters, interfaces, factories and everything else from version one. As an example of a language that gets it right, look at python. You can write your orginal classes in the simplest possible way they could be written, and yet expand from there to just as much architecture as your problem needs without ever touching the users of the class.
    - jbooth 17y ago
      Well, point taken about the getters/setters, those should be automatic or at least managed via keyword or annotation (private gettable String fname or something like that) As for the rest of it.. it's just a question of proper design. If you're just making a utility, you don't need any interfaces or factories. If you're making a module for something that's intended to be run with a half-dozen service dependencies, it's probably a good idea to design it in a way that said dependencies can be injected -- whether you're using spring or doing something more lightweight. That applies across languages, same deal in python.
      - Tuna-Fish 17y ago
        I honestly don't think "private gettable String fname" is in any material way better than getters and setters, as your ide can already insert the boilerplate for you. The problem isn't the boilerplate per se, it's forcing you to think about things before their time. Your attention is a scarce resource. The only satisfactory way for the first version is "public String fname", with the ability to later turn that into proper getters and setters when it is needed without the consumers of the class even knowing. My big point about python is that you can always inject the dependencies, and you don't have to spend any thought beforehand to achieve this. Java could go a long way here with just a few minor changes -- for example, remove "new", you get a new object by calling it's constructor, without any special operators. Allow shadowing of functions. This alone would end the factory madness -- in fact, factories are just an awful boilerplatey way to implement this. For example, if I have a class Foo that needs to instantiate Bar to function, and I want to inject a different bar for some tests (or something), in python I can just: def make_test_foo(): Bar = DummyObjectConstructor return Foo() (this will of course occur only in local scope, so that other potential users in other threads are not going to be stuck with dummy objects against their will) To achieve the same in java, the way I was taught to was to design in a BarFactory for use when needed. In most cases, it's not going to be needed. But if you don't make it, boy are you going to be in a world of pain when you do need it, and half the world already depends on your class. What really irks me about this, is that hotspot is perfectly capable of dealing with these kinds of things -- it is a really nice platform for this kind of dynamicity. Sun just used think that poor programmers are going to be confused when you hit them with too many high-level concepts, and refuses to add constructs like this. Which would be fine, except that the programmers invariably go on to develop their own ugly workarounds, like factories, because they need the power. This I believe to be the big reason why python is so much faster to program in than java. I can program for the now, completely ignoring superfluous architecture when my programs consists of 3 files, with the knowledge that I can safely add it later when needed. The syntax and dynamic typing are just a nice extra.
    - jfager 17y ago
      It's easier to evolve Python programs along that particular axis because of duck typing and dynamic dispatch, but otoh, it's harder to rename or remove methods or change method signatures without thorough unit tests. I really don't think one is better than the other in all cases, and neither really seems to get it 'right' in the sense that there's no room for improvement.
kaffeinecoma 17y ago
We're using Seam. It does DI/IoC using concrete classes, and does not require interface proliferation.
locopati 17y ago
One reply to address the others. Yes, Spring does not require iface proliferation - it just makes life easier when you decide you need different implementations of the same idea if you've committed to ifaces up front. YAGNI still holds true since it's usually easy enough to refactor in an interface when it does become necessary. As far as comments about the ugliness of Java in this regard, I couldn't agree more. However, Java is Java and Python is Python, etc. If you are working in Java, and a lot of people are and don't have the option of switching to something else (think corporate, where what is common and familiar is good), if you are committed to Java, then you must embrace its paradigms. Interfaces and implementation classes are one of those. Enjoy it without fuss and focus on the problem at hand. You'll lose less sleep that way.

jbooth 17y ago

Yes, but generally speaking, if you're writing FooIFace and FooImpl you should probably rethink what you're doing.

jfager 17y ago
Ideally, you'd just get it right the first time, but if you're going to screw up, it's usually better to screw up by having an interface you don't really need than by having a class that should really be an interface. Generalizing that makes it hard for me to agree that FooIFace and FooImpl is, on its own, evidence that something's wrong.
- Tuna-Fish 17y ago
  This does condense what I dislike about java quite nicely. All proper java code is full of speculative architecture and genericity -- in order to have your code easily extensible, you do have to have setters, getters, interfaces, factories and everything else from version one. As an example of a language that gets it right, look at python. You can write your orginal classes in the simplest possible way they could be written, and yet expand from there to just as much architecture as your problem needs without ever touching the users of the class.
  - jbooth 17y ago
    Well, point taken about the getters/setters, those should be automatic or at least managed via keyword or annotation (private gettable String fname or something like that) As for the rest of it.. it's just a question of proper design. If you're just making a utility, you don't need any interfaces or factories. If you're making a module for something that's intended to be run with a half-dozen service dependencies, it's probably a good idea to design it in a way that said dependencies can be injected -- whether you're using spring or doing something more lightweight. That applies across languages, same deal in python.
    - Tuna-Fish 17y ago
      I honestly don't think "private gettable String fname" is in any material way better than getters and setters, as your ide can already insert the boilerplate for you. The problem isn't the boilerplate per se, it's forcing you to think about things before their time. Your attention is a scarce resource. The only satisfactory way for the first version is "public String fname", with the ability to later turn that into proper getters and setters when it is needed without the consumers of the class even knowing. My big point about python is that you can always inject the dependencies, and you don't have to spend any thought beforehand to achieve this. Java could go a long way here with just a few minor changes -- for example, remove "new", you get a new object by calling it's constructor, without any special operators. Allow shadowing of functions. This alone would end the factory madness -- in fact, factories are just an awful boilerplatey way to implement this. For example, if I have a class Foo that needs to instantiate Bar to function, and I want to inject a different bar for some tests (or something), in python I can just: def make_test_foo(): Bar = DummyObjectConstructor return Foo() (this will of course occur only in local scope, so that other potential users in other threads are not going to be stuck with dummy objects against their will) To achieve the same in java, the way I was taught to was to design in a BarFactory for use when needed. In most cases, it's not going to be needed. But if you don't make it, boy are you going to be in a world of pain when you do need it, and half the world already depends on your class. What really irks me about this, is that hotspot is perfectly capable of dealing with these kinds of things -- it is a really nice platform for this kind of dynamicity. Sun just used think that poor programmers are going to be confused when you hit them with too many high-level concepts, and refuses to add constructs like this. Which would be fine, except that the programmers invariably go on to develop their own ugly workarounds, like factories, because they need the power. This I believe to be the big reason why python is so much faster to program in than java. I can program for the now, completely ignoring superfluous architecture when my programs consists of 3 files, with the knowledge that I can safely add it later when needed. The syntax and dynamic typing are just a nice extra.
  - jfager 17y ago
    It's easier to evolve Python programs along that particular axis because of duck typing and dynamic dispatch, but otoh, it's harder to rename or remove methods or change method signatures without thorough unit tests. I really don't think one is better than the other in all cases, and neither really seems to get it 'right' in the sense that there's no room for improvement.

kaffeinecoma 17y ago

We're using Seam. It does DI/IoC using concrete classes, and does not require interface proliferation.

locopati 17y ago

One reply to address the others. Yes, Spring does not require iface proliferation - it just makes life easier when you decide you need different implementations of the same idea if you've committed to ifaces up front. YAGNI still holds true since it's usually easy enough to refactor in an interface when it does become necessary. As far as comments about the ugliness of Java in this regard, I couldn't agree more. However, Java is Java and Python is Python, etc. If you are working in Java, and a lot of people are and don't have the option of switching to something else (think corporate, where what is common and familiar is good), if you are committed to Java, then you must embrace its paradigms. Interfaces and implementation classes are one of those. Enjoy it without fuss and focus on the problem at hand. You'll lose less sleep that way.