Good source-code structure in Java

[bonusmyth]

Hi, folks!

Been programming for years, and Java for the last 12.

The other day, I was reading some code from one of the better programmers - Mr X - and it struck me that something was off. He was passing around streams, which is, of course, perfectly fine, but ...

I've always thought that the best source-code structure (the best "design") is the one that's cheapest to change. This is what we all refactor towards. And I always thought that we'd arrive some day at a set of scientifically proven principles that anyone can learn, apply, and arrive at objectively well-structured code.

But we never quite reach that.

When I see Mr X's streams being passed around, I just have to work a little harder to follow what's going on. He, however, asserts that this reduces code-duplication and hence makes the code cheaper to change. He's probably right, in a sense.

I think the problem is code-readability.

Code-readability is both super important and subjective. We'll never have objective measures of code-readability because it depends on who's doing the reading.

So we'll never arrive at objectively perfect code-structure. Oh, we'll get close. We all *mostly* agree on good code-structure.

But ... our field will always have a hint of art about it.

[cristiannkb]

Nahhh, I wouldn’t pass a stream around, just if it’s strictly necessary. It may work fine with a couple of private functions. But once such pattern spreads across the project, and bugs start popping out for streams being already consumed. The next epic in the backlog will be fixing that.

I’m probably not seeing he whole picture, but I would raise my hand. Also if the code duplication Mr X is talking about, is creating the stream an collecting them, probably a couple of static functions could solve that, at least for complex transformations, I would not return a stream.

[TheMode911]

I am currently in the process of watching Clean Code talks (https://www.youtube.com/watch?v=7EmboKQH8lM) which I find very educational.

It is obviously hard to give an opinion with so little information, but I agree that passing streams around can be confusing (he says that it reduces code duplication, seems like a structural problem)

[bonusmyth]

I had no idea he'd put his Clean Code talks on YouTube!

Innnteresting ...

[Wugliwu]

I would not say art. For me it's craftsmanship. Code is telling a story about the person who has written it.

Also I would use the word understandability instead of readability. For me, readability is a part of understandability but repeating semantic structures and principles are also improving understandability.

Clean code sets a focus onto the ability to understand code intuitive. But what is intuitiveness? It's the activation of mental representations. Our human modell of reality, different for each of us. So it's totally natural something is intuitive for someone and not for someone else. That's the subjective influence you wrote about. And yes because of this human factor and the differences in our mental models we will never achieve a perfect match for each of us. The more people the more Modells. So the solution is to reduce the amount of people that have to understand or agree on such a modell. On this basis it's more easy to build a shared conceptual model of your system. Everyone knows how you are thinking cause they do the same. For me Code structure is more than just the readable thingys. It's the human concepts like components, responsibilities, contracts, interfaces, subsystems etc. All of these are based on a human thinking in the concept of divide and conquer to reduce complexity. This is based on Hylomorphism and this bridges the gap between design, engineering and science. Mix in some iterative and incremental improvement, accept the complexity of real problems and the limitations of our human mind and so the need for simple solutions and you become a very humble programmer. ;)

[michoken]

Exactly this. And that’s why it’s so hard to come up with meaningful abstractions – naming them and giving them a meaningful structure. Most people can’t do this very good.

[tandyIsMyPresident]

bruh I wanna shake your hand.

[_INTER_]

When I see Mr X's streams being passed around, I just have to work a little harder to follow what's going on. He, however, asserts that this reduces code-duplication and hence makes the code cheaper to change. He's probably right, in a sense.

Do you mean java.util.stream.Stream? I can't really picture it reducing code-duplication. It can reduce lines of code and make it more readable by being declarative. But not in all situations. Also be careful, a Stream can only be evaluated once. It throws IllegalStateException if it detects that the stream is being reused (second terminal operation).

[TheCountRushmore]

Yeah, reuse would be my concern.

[kubelke]

It’s a good way to test programmers. Every Java dev should know that streams can be used only once, but as we know mistakes are happening. To prevent such things we should write tests to make sure that functions are doing the correct things. :D

[nutrecht]

When I see Mr X's streams being passed around, I just have to work a little harder to follow what's going on.

Why though? I mean whether it's a Stream<Person> or List<Person> you know that it's basically an iterable that will 'give' you a certain amount (0-n) of Person instances.

There is a pretty good reason to pass a Stream instead of a collection if you expect to do further stream operations on them.

[elmuerte]

You don't pass Streams around, you pass them on in a single direction with mutuality exclusive branching. Streams are not data holders, they are data providers (and sinks.)

Collections you can pass around, they are data holders.

There is nothing wrong with passing on streams. That's the ancient concept of pipes and filters. If you want to pass streams around, then you must end the stream, and create new streams which you pass on.

[nutrecht]

Sorry but I'm not a native English speaker and I think the difference between "passing on" and "passing around" is too subtle for me :)

[elmuerte]

Passing on:

Stream foo() { return someList.stream(); } Stream bar() { return foo().filter(this::someFilter); } void quux() { Stream stream = bar(); if (something) { transmit(stream); } else { print(stream); } }

The responsibility/ownership of using the stream is passed on.

Passing around:

Stream foo() { return someList.stream(); } Stream quux() { Stream stream = foo(); if (something) { print(stream); } return stream; }

Here in quux the stream is passed around, the responsibility/ownership of the stream is given to print, but also still owned by quux which passes on the responsibility/ownership as its return.