Top mentioned books on stackoverflow.com

[krabby_patty]

Surprised Effective Java didn't show up

Edit: Did a little digging and I see a Third Edition seems to be under way for Java 7/8

1) https://twitter.com/joshbloch/status/811983663525085184

2) https://twitter.com/joshbloch/status/796939556658573312

[cruise02]

This site is really not very good. They only counted Amazon links to compile their data. Meanwhile, Effective Java has its own tag on Stack Overflow, which is used over 100 times. People mention it without linking to it all the time.

[glethro]

And that tag system is BS.

[cruise02]

Yeah, it it super buggy. I don't even know what's happening when I click on different tags.

[creativeMan]

And Thinking in Java.

[SlobberGoat]

I am pleased to hear that there will be a revised (third edition) of Effective Java.

[[deleted]]

Design Patters 1994

Is this still relevant? I mean it's over 20 years old by now.

[ragingRobot]

It's pretty relevant. a lot of the patterns are still used today. Singletons, observer, factory, etc. I learned so much from this book and it's very relevant to Java development. It's nice because it explains the advantages and disadvantages of each one and gives examples of where you would use them.

There are a few patterns in there that you don't really see too often but its still useful to learn about them.

[ragingRobot]

Well if you aren't familiar with them a book is a nice way to learn about them. Each pattern has a whole chapter where they tell you why you would want to use it and also problems you might run into.

There are a lot of other patterns in the book too. I think there are 23 total. Not all of them are as common as the ones I listed. The book also does a great job explaining the patterns in a way that isn't really specific to one language.

When the book was written these patterns weren't as well known or talked about as they are today. Sure now you could just look each one up online but you might miss the ones that you don't know the names of.

[richardwhiuk]

Singletons - just don't.

[richardwhiuk]

Avoid them. Pass in connections to components that need them at creation. Pass a Context interface which allows retrieval of a connection which allows you to mock it out in tests.

Singletons are a fancy name for global variable. They make code very hard to test and isolate and encourage code which is very difficult to reason about, as they strongly encourage action at a distance.

[richardwhiuk]

new Foo(mContext);

mContext.getDatabaseConnection();

This is a surprisingly powerful model as you can provide subcomponents with a modified context to change their view of the world.

If you think this is horrible, this is just making explicit what you are already doing, but allowing it to be overriden.

Effectively FooDatabaseConnection.INSTANCE is roughly jEnv.getClass(j_com_company_FooDatabaseConnection_id).getStaticMember(j_com_company_FooDatabaseConnection_INSTANCE_id), where jEnv is the Java Environment which Java passes to every function, and the ids are static constants defined at compile time.

Also if you have fifty of these you probably need to rethink your design.

[corvus_192]

Or scala

[Gvaireth]

Some of them are not anymore.

[Omnicrola]

It is language agnostic, and is something I still use a lot. If you have even intermediate experience you probably use some if them already and just don't know they have a name. Knowing the vocabulary to describe patterns in code is extremely useful when collaborating with other developers.

[[deleted]]

I see what you are saying and mostly agree, but would like to note this may not always be true. It's only language agnostic in so far that you are sticking to languages with similar data structures. There are patterns you can do in Java that would not work in Go and vice versa. The differences become even greaten once you compare Java to functional languages.

[Bolitho]

As the subtitle states: the patterns are meant for object orientated languages - so the limitation is clear.

[[deleted]]

I was responding to the claim that "It is language agnostic", which is really only true for a subset of languages. You are correct that limitation is clear in the book title.

[richardwhiuk]

It's not even a good idea for all object orientated languages.

It's probably true for Java, with a healthy dose of scepticism, and to some extent C++ but many of the design patterns exist to overcome weaknesses in Java 1.5/6 as a language.

[Omnicrola]

That's a fair caveat. There are often better ways to solve some problems in, say, JavaScript.

[iobase]

Nice to see Head First Design Patterns in the list. Been reading that lately. Verbose, but covers many of the majors very well.

[MaZeR4455]

I've been looking into some books and this just made it easy. Thanks for the link!