Abuse of Lambdas

So, sometimes when you have an existing software structure, with lots of domain rules inside, it becomes difficult to change. Especially when there is a lot of cohesion between your classes.

This is the problem of tight coupling, as opposed to loose coupling¹.

I recently encountered this in our software.

And of course, I needed to change something deep inside.

Now, I didn't need to change anything about the domain logic. It was very good and working as intended.

But I needed a change purely for technical reasons. In this case, the domain logic was used in a Batch Processing on Hibernate Entities, and the domain logic was (in this case, not normally) generating a lot of Entities, and they were all persisted in the Session Context, which naturally grew. And then the dirty check and the session closing takes a long time, etc, etc. See reference [2] on why this's bad.

So I was looking for a way to persist entities, without adding them to all the collections with the CascadeType without changing the domain logic too much, and also keep the default behaviour as standard.

I didn't want to use inheritance, as it was a persisted Hibernate Entity.

So, I came up with the following hack:

Quite simply, I can now add behaviour to an Entity when I need it.

For example:

As me and my colleague say "A seemingly innocent first step on a slippery slope to hell."

Of course, this kind of abuse has always been possible, but it is now easier to do than ever (without having to create an entire class for the priviledge).

References

[1] Wikipedia - Loose coupling

https://en.wikipedia.org/wiki/Loose_coupling

[2] Vlad Mihalcea - The best way to do batch processing with JPA and Hibernate

https://vladmihalcea.com/the-best-way-to-do-batch-processing-with-jpa-and-hibernate/

Abstraction Considered Harmful

One of the more thought-provoking pieces I have read in a long time, and one I happen to fully agree with, having seen myself what too much Abstraction can lead to:

http://bravenewgeek.com/abstraction-considered-harmful/

I like the quote:

“duplication is far cheaper than the wrong abstraction”

Feature Creep

From Wikipedia^[1]:

“Feature creep, creeping featurism or featuritis is the ongoing expansion or addition of new features in a product, such as in computer software.”

It carries with it negative connotations of over-complicating the design, adding features that are unrelated to or go beyond the original function of the program, adding features that are of no additional value to the users because software developers thought it would be a 'good idea'™.

In a worst case scenario Feature creep could result in the original program becoming a 'platform' or 'framework'. Though, I doubt it not that many good frameworks originally started out this way.

An example

The example I wish to focus on today is the widget displayed in the upper-left corner of the article. We've recently installed a 'smart' electricity measuring device, which can be bolted onto the original Electricity meter.

Now, I have certain assumptions about the software that was included, namely that it would show me my consumption of electricity over time, possibly using nice colourful graphics.

And it does do that, make no mistake, and I am very happy with it.

But why, oh why, did they add an RSS Feed to nu.nl (a Dutch newssite) to the widget? Did the developers think it's a good idea? Did they have the implementation of the RSS feed lying around, and thought, 'hey, why not cram that in there as well?'. Did they think 'Oh, when someone wishes to check the news, they'll naturally check our energy widget?' Does it have any added value for me as a customer at all?

Why? Can someone please tell me?

References

[1] Wikipedia - Feature creep

http://en.wikipedia.org/wiki/Feature_creep