8 ms·

I have the same personal rule. Too often junior engineers think that the worst cardinal sin is to have a small amount of duplicated or less abstract than it cou

by nupark2 15y ago

I have the same personal rule. Too often junior engineers think that the worst cardinal sin is to have a small amount of duplicated or less abstract than it could be code. This really isn't the case. Until you really understand the commonality of the problem, attempting to abstractly define the solution will make your future work all the more difficult when it turns out you didn't really understand all the edge cases and exceptions. Three use cases are a good number -- by that time you're much more likely to understand the problem, and by avoiding premature abstraction, you'll have an easier time doing the work.

cpeterso 15y ago
Another problem is that Java and C++ developers often use class inheritance to share implementation code, even if the classes are not modeling proper is-a relationships.
- agentgt 15y ago
  Actually I think a bigger problem is that Java programmers (not C++) create hundreds of interfaces. Thus Java becomes an artifact hell (EJB 2.0 was a nightmare). Abstract classes on the other hand are very useful but most Java programmers think... "well what if in the future I need...". If Java just had traits/mixins, closures, literals, and some syntax brevity it would be a pretty damn descent language... oh wait that's Scala.
  - ebiester 15y ago
    No, that's Groovy. Scala is the equivalent of C++ - trying to be everything to everyone and creating an expansive behemoth that everyone picks their own subset from.
    - soc88 15y ago
      Sounds like you never actually used it.
    - sreque 15y ago
      A dynamic language that is 100-1000x slower (http://stronglytypedblog.blogspot.com/2009/07/java-vs-scala-vs-groovy-performance.html http://stronglytypedblog.blogspot.com/2009/07/java-vs-scala-...) does not equal Java plus closures and a few other syntactic niceties. You would have been much more accurate referencing Xtend, Kotlin, Gosu, or Ceylon.
  - timclark 15y ago
    You don't have to create an interface! One of my favourite interview questions is why do you use interfaces in Java? The majority of people I interviewed said that it a good design used interfaces and had nothing more to say. In code review if you have an interface and only one implementation I'd make you remove the interface - I call this the unnecessary Impl pattern since the class is traditionally called NameOfInterfaceImpl. Also you don't have to name property accessors getX() and setX() if you don't want to.
    - neeleshs 15y ago
      Interfaces are a (or used to be ) huge help with unit tests with mocking etc. With better class mocking libraries now, that advantage has diminished.
    - VladRussian 15y ago
      > In code review if you have an interface and only one implementation I'd make you remove the interface which changes the contract from "this component will accept and work with anything implementing this interface" to "this component will accept and work with anything of this class or inheriting from this class". And without multiple inheritance ... Do you feel the difference?
      - reddiric 15y ago
        If there is only one implementation of an Interface, "anything implementing this Interface" and "anything of this class" are the same thing. Coding to an interface is a good thing - but it's the concept "interface", not necessarily the language feature named "Interface" that's important. If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface (you were coding to a conceptual interface representing a consistent abstraction of a single responsibility in the beginning so your Interface is interchangeable, correct?)
        VladRussian 15y ago
        > If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface you're a lucky person that it has been trivial for you, your teammates and all the known and unknown clients of your code and components. I can only envy your experience.
  - tikhonj 15y ago
    Scala is a very different beast from Java. It has all that you mentioned, to be sure, but it also has a lot more. You should check out Gosu[1], which is a language that does exactly what you say without adding complexity or being as different from Java as Scala. [1]: http://gosu-lang.org http://gosu-lang.org
  - spullara 15y ago
    Actually, that is probably a future version of Java. JDK 8 will have closures and something very much like mixins.
- wbkang 15y ago
  I used to think that way too but actually inheritance doesn't have to imply an is-a relationship. Inheritance in its basic form in programming language theory can be thought as a code inclusion mechanism. To be honest, I often find that composition is a poorer and clunky way to reuse code
dustingetz 15y ago
I've never seen a java team that actually bothered to write something three times. You do it once, it sucks, you shrug because of your deadline, a ball of mud gets wrapped around it, development pace slows way down, and oh shit, it's too late to change. IMO get it as right as you can, the first time. (i work for a small, competent, enterprise java shop)
- nupark2 15y ago
  If you're not going to re-use something, then why are you writing it to be re-usable?
  - calebmpeterson 15y ago
    Because something designed to be reusable was probably designed with an eye towards reading the code a lot and may also (incidentally?) be more well factored?
    - nupark2 15y ago
      Which circles back around to the point above; until you have a few examples, trying to make something reusable will probably cause you more pain in the long run. That's not justification for bad code, just an argument against premature factorization. Like recommendations against premature optimization, it's just a good rule of thumb.
  - dustingetz 15y ago
    the "big ball of mud" that gets wrapped around factoring-1 IS the re-use. its not like a team writes one component, then says "OK we're done!" and writes the next. you write your infrastructure hand-in-hand with the code that uses it. but as you understand your infrastructure problems, you don't fix them, because "we'll just write a few more things around it for this milestone". for the next five milestones. software human process doesn't happen in nice, discrete chunks which are easy to understand, talk about, and justify.
- buff-a 15y ago

by nupark2 15y ago

cpeterso 15y ago

Another problem is that Java and C++ developers often use class inheritance to share implementation code, even if the classes are not modeling proper is-a relationships.

agentgt 15y ago
Actually I think a bigger problem is that Java programmers (not C++) create hundreds of interfaces. Thus Java becomes an artifact hell (EJB 2.0 was a nightmare). Abstract classes on the other hand are very useful but most Java programmers think... "well what if in the future I need...". If Java just had traits/mixins, closures, literals, and some syntax brevity it would be a pretty damn descent language... oh wait that's Scala.
- ebiester 15y ago
  No, that's Groovy. Scala is the equivalent of C++ - trying to be everything to everyone and creating an expansive behemoth that everyone picks their own subset from.
  - soc88 15y ago
    Sounds like you never actually used it.
  - sreque 15y ago
    A dynamic language that is 100-1000x slower (http://stronglytypedblog.blogspot.com/2009/07/java-vs-scala-vs-groovy-performance.html http://stronglytypedblog.blogspot.com/2009/07/java-vs-scala-...) does not equal Java plus closures and a few other syntactic niceties. You would have been much more accurate referencing Xtend, Kotlin, Gosu, or Ceylon.
- timclark 15y ago
  You don't have to create an interface! One of my favourite interview questions is why do you use interfaces in Java? The majority of people I interviewed said that it a good design used interfaces and had nothing more to say. In code review if you have an interface and only one implementation I'd make you remove the interface - I call this the unnecessary Impl pattern since the class is traditionally called NameOfInterfaceImpl. Also you don't have to name property accessors getX() and setX() if you don't want to.
  - neeleshs 15y ago
    Interfaces are a (or used to be ) huge help with unit tests with mocking etc. With better class mocking libraries now, that advantage has diminished.
  - VladRussian 15y ago
    > In code review if you have an interface and only one implementation I'd make you remove the interface which changes the contract from "this component will accept and work with anything implementing this interface" to "this component will accept and work with anything of this class or inheriting from this class". And without multiple inheritance ... Do you feel the difference?
    - reddiric 15y ago
      If there is only one implementation of an Interface, "anything implementing this Interface" and "anything of this class" are the same thing. Coding to an interface is a good thing - but it's the concept "interface", not necessarily the language feature named "Interface" that's important. If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface (you were coding to a conceptual interface representing a consistent abstraction of a single responsibility in the beginning so your Interface is interchangeable, correct?)
      - VladRussian 15y ago
        > If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface you're a lucky person that it has been trivial for you, your teammates and all the known and unknown clients of your code and components. I can only envy your experience.
- tikhonj 15y ago
  Scala is a very different beast from Java. It has all that you mentioned, to be sure, but it also has a lot more. You should check out Gosu[1], which is a language that does exactly what you say without adding complexity or being as different from Java as Scala. [1]: http://gosu-lang.org http://gosu-lang.org
- spullara 15y ago
  Actually, that is probably a future version of Java. JDK 8 will have closures and something very much like mixins.
wbkang 15y ago
I used to think that way too but actually inheritance doesn't have to imply an is-a relationship. Inheritance in its basic form in programming language theory can be thought as a code inclusion mechanism. To be honest, I often find that composition is a poorer and clunky way to reuse code

dustingetz 15y ago

I've never seen a java team that actually bothered to write something three times. You do it once, it sucks, you shrug because of your deadline, a ball of mud gets wrapped around it, development pace slows way down, and oh shit, it's too late to change. IMO get it as right as you can, the first time. (i work for a small, competent, enterprise java shop)

nupark2 15y ago
If you're not going to re-use something, then why are you writing it to be re-usable?
- calebmpeterson 15y ago
  Because something designed to be reusable was probably designed with an eye towards reading the code a lot and may also (incidentally?) be more well factored?
  - nupark2 15y ago
    Which circles back around to the point above; until you have a few examples, trying to make something reusable will probably cause you more pain in the long run. That's not justification for bad code, just an argument against premature factorization. Like recommendations against premature optimization, it's just a good rule of thumb.
- dustingetz 15y ago
  the "big ball of mud" that gets wrapped around factoring-1 IS the re-use. its not like a team writes one component, then says "OK we're done!" and writes the next. you write your infrastructure hand-in-hand with the code that uses it. but as you understand your infrastructure problems, you don't fix them, because "we'll just write a few more things around it for this milestone". for the next five milestones. software human process doesn't happen in nice, discrete chunks which are easy to understand, talk about, and justify.
buff-a 15y ago