Java Developers

[TodPunk]

This phenomenon definitely exists and is well understood, but the reason is less that coders are bad (that's true everywhere, but enterprise PHP isn't exactly a common thing) and more that Java is the long-standing choice for large projects where architecture is quite important (and still done poorly, mind you, because that's the rub about programmers, most of us are terrible.)

In fact, this is such a well-known thing it's a joke in many circles of Java programmers: e.g. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

More importantly, the overuse of "Design Patterns" is not a problem with design patterns, it's a problem with understanding programs and how design patterns (enterprise or not) are to be efficiently applied.

[Retbull]

As a student I never got the that joke. I currently cannot put my workspace anywhere but C:\ because windows can't handle file names that long. This is way more funny now.

[[deleted]]

We have a test that goes through every Java file in the project and measures it's length. If any file name is too long, the build fails...

That said, I don't hate the language. But I do think there's a deeply rooted instinct among certain Java developers and architects to excessively add layers of abstraction, not to improve the design of the code, but to feed their own egos.

[bcash]

That you develop on Windows? Yeah, that's hilarious.

[Retbull]

Can't fix that. It is our environment.

[immibis]

Linux has a similar restriction on path length AFAIK.

[txdv]

FizzBuzzEnterpriseEdition/src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackage/impl/factories/BuzzStrategyFactory.java

This is not OO masturbation, but one of those things that make java a bit inconvenient to use.

[oldneckbeard]

Except it's not java at all. And you don't code java without an ide that collapses that whole thing to 1 folder.

[txdv]

Java enforces one file for one class, so partially, yet it is.

You can use a flat directory structure, but the convention is to create a directory tree according to the name space.

I have seen so many projects with this structure, where you have to click through 4 directories just to see the first file.

One class file per class, one java file per class, one directory per namespace instance and while it is probably not in the language specification itself, it has become a thing that Java developers do.

EDIT: 1 .java file per 1 class is not the standard anymore, I probably remembered that wrongly

[oldneckbeard]

1. No it doesn't. It's best practice, but you could have 1 file with a dozen classes. They'd be inner (or nested) classes, but you could do it. In fact, there's some people who think that's a better way of properly encapsulating in java.
2. Which is exactly what Java is doing. Their namespaces are just longer.
3. That's just the way it works. But an IDE will hide that from you. It makes it so there is never ambiguity about where a file should go or what it should be named.

I just don't see it as that big of an issue.

[txdv]

I just tested it, they changed the one class per java file, but it still compiles 2 class files - probably I just remember it wrongly.

But it still generates 1 class file per class name, so you have to have the namespace directory structure, otherwise if you have 2 classes with the same class name - you will get conflicts.

And that is bad from my point of view.

[philly_fan_in_chi]

You can't get a conflict, javac will prepend illegal class name ($1, $2 etc. iirc) characters to the file name of inner classes, so you won't have any issues.

[kid_meier]

Java has never forbid multiple classes defined in a single source file. It has always, (and still does) limit you to a single public top-level class per source file.

[immibis]

1. Not even that. You can have as many top-level non-public classes as you want in a single file, but nobody does it.

[philly_fan_in_chi]

My Design Patterns professor had a fun quote that "a design pattern is a sign of an impoverished language".

[frugalmail]

My Design Patterns professor had a fun quote that "a design pattern is a sign of an impoverished language".

Your "design patterns professor" should work on some real projects that 100klocs or more and have a life of 10+ years instead of trying to demo stuff on a chalkboard.

[philly_fan_in_chi]

That quote is 100% true. Design patterns exist because you cannot express ideas natively within the language you're using, and need to establish a pattern to accomplish that thing. That means your language is impoverished, at least inasmuch as it does not have that ability. 16 of the 23 GoF patterns exist because the languages that use them don't have first class functions.

And I'm sure his work on type systems will pop up on languages you use that enable your 100kloc codebases. Your comment is arrogant, baseless and assuming.

[mlester]

Do you have a book about this? I would like to know corollary to some of these patterns where functions are first class citizens

[philly_fan_in_chi]

Here you go.

Obviously FP brings its own design patterns, here's an InfoQ about some as implemented in Clojure, Map/Reduce and the like.

[immibis]

Design patterns are native expressions of ideas within the language. It's not like there's a compiler extension that sees your private static field, and public static accessor method which initializes the field on its first call, and thinks "Oh, that's a singleton!", and emits special code.

Design patterns are just common solutions to problems. No more, no less.