

Java Doesn't Need to Be So Bad - dugmartin
http://twitch.nervestaple.com/2011/12/04/java-patterns/

======
btilly
A good rule of thumb that has served me well.

Never try to abstract something until I'm on my third implementation of
something like it. The first time I lack context for what is likely to change.
The second time you have to watch out for second system effect, adding all of
the things you wanted in the first version. But the third time you tend to
have the experience and knowledge to do it right.

This is a rule of thumb that should be drilled into the heads of anyone who is
even _thinking_ of drinking the patterns kool-aid.

~~~
geophile
I was about to say the same thing myself. For some reason, a lot of developers
(including me) go through a phase in which they generalize as much as possible
as early as possible. This completely misses the obvious: It is harder to plug
into an abstraction, especially a bad one, than it is to do the simplest thing
and generalize later, when you need to.

Oh, and by the way: death to injection frameworks. I want my java code to be
readable, tangible java code.

~~~
boyter
Totally agree with the death to injection frameworks. Where I work a lot of
the devs love to talk about "dependency injection" and ways to have some
abstracted thing in .NET handle it for you.

My preference has always been have a constructor which takes in the interfaces
required. Its very explicit, makes testing a breeze and with no magic is much
easier to read.

~~~
nigelsampson
Agreed, constructor injection is pretty much the only type of "dependency
injection" that makes sense to me.

The less magic the better.

------
cemerick
The "I Point the Finger at You, I Have Already Pointed it At Myself" section
calls me out for sure…

    
    
        I personally have to live with the shame of a very clear and vivid memory
        wherein I circled objects that covered nearly four sheets of this paper
        and wrote, in my own hand and with a clear-head: "A good candidate for an
        abstract factory! :)"
    
        Eventually I realized that the emoticon was mocking me. Laughing at my
        presumptuousness, laughing at my premature optimization.
    

10-12 years ago, I was that guy trying to spot "patterns". Ugh. Hopefully my
Clojure hacking will tip my karmic balance back to neutral.

~~~
babebridou
I've got a serious mental contingency bomb setup to explode whenever my mind
wanders and thinks about reflection. I think about it, the bomb explodes, I
stand up and go for a walk and when I come back the whole thought process that
lead me to consider reflection is wiped clean, ready for a fresh redesign from
scratch.

It's not that I don't see value in Reflection, it's just that I'm sick of
debugging it.

Abstractfactories are not that bad, actually if you're in the habit (like me)
to always step in and write an interface before you start any abstract, you
pretty soon understand why it's a good or bad idea - interfaces of factories
are so damn trivial that even an abstractfreak will see this as redundant work
and will want to write an interface of this factory interface and then a
factory interface factory through code injection, preferrably through
annotations, but it could be from other means such as a properties file or xml
configuration, so they think about a factory interface abstract factory (and
of course its interface). By then, even the craziest persons give up and just
do their job.

------
resnamen
It doesn't need to be so bad, but in larger organizations, it often is so bad.
It just takes a few bad seeds of pattern-zealotry in an organization to poison
the codebase into a God-awful mess. Once the patterns become a common
practice, and every constructor has been dependency-injected ad nauseum
(despite most interfaces having only ever having 1 implementation), there's
just no going back.

~~~
devonrt
It's not just larger organizations. I've seen exactly what you're citing —
where even the most trivial objects were injected — in an organization with
roughly 5 developers.

------
revscat
Java doesn't _need_ to be, but frequently is.

Non-reified generics with their ridiculously verbose syntax are the first
thing that came to my mind. God forbid you should try to write your own class
which uses them.

Not to mention that since spending almost decade of my career working with
Java I have since worked with languages that do not have generics, and have
not suffered thereby. Generics are, IMO, largely unnecessary.

Yes, this is a small subset of Java, but it is one that continually annoyed
me.

~~~
tsewlliw
Java generics _are_ ugly, but I'd rather write Java with them than without
them.

~~~
SeanLuke
I'm quite the other way around.

------
ap22213
Well, I for one frequently encounter places where the factory / interface /
adapter paradigm is a good solution. And, it's not just to be clever.

This typically occurs when 1) I am doing enterprise application development,
and there are many different instantiations of a particular application, or 2)
I am doing enterprise integration, and I have many different libraries and
services to work with, sometimes legacy, and often with complex business logic
that selects some over others.

Granted, I've seen this pattern used all too often and seen over-abstraction,
in general. But, I need to be brave and defend this, given that no one else
seems to want to. It does have some legs.

I use this when working with a lot of different teams / companies and
coordinating them all and agreeing to how things will work in production.
That's especially true when some of those teams / companies may be
interchanged with others. This type of solution makes a lot of sense.

However, I would much prefer a dynamic typed solution to avoid the unnecessary
boilerplate. And, even better, I would prefer to work only with self-contained
software companies that have complete control over their code-base and
restrained domain logic. That would be awesome! (but wishful thinking).

------
swah
We could have a poll... What percentage of folks use Java because they want vs
because they must? Would you use Java for your startup? With which stack?

~~~
hello_moto
Yes. In fact there's one idea that I'm sort of prototyping right now in which
Java would be a nice fit due to WebService integration.

Do I want or must use Java? Does not matter to me. The libraries (and their
quality) help me write less code and make me feel comfortable (it is
psychology, but it matters).

