7 ms·

Having a clear, short and concise overview of public API is a good thing. interface allows for that. Object Pascal had this feature by default: you have to decl

Having a clear, short and concise overview of public API is a good thing. interface allows for that. Object Pascal had this feature by default: you have to declare public methods and then implement it in a different section. I always missed that in Java and separate interface allows to recreate that pattern. Sure, you might want to say that I should just use IDE which will show me all public methods in a GUI tree control. But I don't like it, I like code. May be some feature which completely hides anything in the class except public method declarations could substitute, but I did not see that feature yet. Honestly I don't know what's wrong with an interface, even if there's a single implementation. Idea and Eclipse allows you to jump to implementation with a single click if that's what you're looking for. JIT will replace virtual method calls with direct ones.

imtringued 6y ago
>Honestly I don't know what's wrong with an interface, even if there's a single implementation. I once had to work on a code base where every SQL query was inside a DaoImpl (ok) which was an implementation of a Dao interface (questionable) which is then called by a BoImpl (why on earth?) which is an implementation of a Bo interface. By your logic it would be sensible to add even more interfaces even though the intermediate classes do nothing except pass a function call to the next layer. Want to add one parameter to an SQL query? Well vbezehnar said it's fine to modify 6 or 8 files to accomplish such a trivial task. The irony is that the whole code base was garbage and hardly readable and the biggest culprits weren't the overuse of patterns (they were just the cherry on top) but rather the fact that a random bundle of libraries has been misused for purposes that they were not designed for. My personal favorite is keeping hibernate objects beyond the lifetime of a hibernate session and the hibernate session was configured to live as long as the http request. Combine this with a web framework that completely abstracts away http requests and it means you can never use hibernate correctly because you never know when the session has expired.
raducu 6y ago
I don't know why leaving a class package protected is such an eyebrow raising thing. Even code analysis tools flag it with a warning. Most classes shoud not be accessible outside their package. That would raise some questions with guys who advocate lots of interfaces -- where and who exactly is going to need this interface?

imtringued 6y ago

>Honestly I don't know what's wrong with an interface, even if there's a single implementation. I once had to work on a code base where every SQL query was inside a DaoImpl (ok) which was an implementation of a Dao interface (questionable) which is then called by a BoImpl (why on earth?) which is an implementation of a Bo interface. By your logic it would be sensible to add even more interfaces even though the intermediate classes do nothing except pass a function call to the next layer. Want to add one parameter to an SQL query? Well vbezehnar said it's fine to modify 6 or 8 files to accomplish such a trivial task. The irony is that the whole code base was garbage and hardly readable and the biggest culprits weren't the overuse of patterns (they were just the cherry on top) but rather the fact that a random bundle of libraries has been misused for purposes that they were not designed for. My personal favorite is keeping hibernate objects beyond the lifetime of a hibernate session and the hibernate session was configured to live as long as the http request. Combine this with a web framework that completely abstracts away http requests and it means you can never use hibernate correctly because you never know when the session has expired.

raducu 6y ago

I don't know why leaving a class package protected is such an eyebrow raising thing. Even code analysis tools flag it with a warning. Most classes shoud not be accessible outside their package. That would raise some questions with guys who advocate lots of interfaces -- where and who exactly is going to need this interface?