Data Oriented Programming in Java: Chapter 5 Progress (2024-11-03)

Published: 2024-11-03

Current Stats:

• Words: 14,102 (all still phenomenal trash)
• Listings: 20
• Figures Used: 13
• Figures Made: 46
• SLoC (repo): 1,171(ish) (currently in a state of flux)

I think I've reached the Peak of Complexity. There are a ton of words. Most of them bad. Many of them devoted to irrelevant nonsense (do I need to talk about HomSets...?). But the overall shape is there. It now a matter of trimming it down.

I decided to stick with the Service Oriented Hellscape approach, but just scale back how much of that hell we have to deal with. People reading this book probably won't care about the intricacies of how accounting systems work at $MegaCorp or what a general Ledger is, or why it's centralized. For more than a few weeks, I was expecting people to read, understand, care about, and follow as a requirement the fact that book closing is distinct concept from calendar date.
Boring.

My biggest worry in this chapter is approaching anything that resembles a strawman of Java. There's obviously no way to make everyone happy, but hopefully I can make it so that nobody is actively upset. Few things are more annoying watching someone smugly dunk on a programming approach that hasn't been used in 20 years (i.e. one of the worst parts of the Clojure community).

I've spent hours crawling private code at Amazon and public code on Github to cobble together what I think is a fair approximation of "most" Java code. Even if you don't see it as what you'd personally write, I hope that you would recognize it as familiar. Something that you might see in a code review.

Here's my take: modern Java isn't object oriented, or data oriented, or functional. It's largely framework oriented. Tools like Spring and Hibernate dominate how Java code is written. The patterns they encourage can be seen even in codebases that aren't using those specific tools. The thought patterns are embedded into the community's consciousness. This influence where we start and what kind of abstractions we make.

So, I've slowly talked myself into this being an OK starting point. (I was very unsure of it last week)

class FeeChargingService {
	// stuff we integrate with to do work 
	RatingsClient ratingsClient; 
	ContractsClient contractsClient; 
	ApprovalsClient approvalsClient; 
	BillingSystem billingSystem; 
	// Stuff we own 
	CustomerRepo customerRepo; 
	InvoiceRepo invoiceRepo; 
	RulesRepo rulesRepo; 
	FeesRepo feesRepo; 

	public void createLateFees(LocalDate bookClosing) {
		// And so we begin! 
	}
}

Plan for the next week

I'm in the home stretch for the first draft (which is really always closer to, uh, the 1000th draft). The shape is mostly clear, it's a matter of grinding out the rest and kicking it over the line.

After that, the next part of the process usually goes like this: I kick it over to Brian Goetz, he tells me it sucks, I mope for a few days, curse his big dumb stupid name, complain internally about my unrecognized genius, but then slowly realize he's right, and that I might not be a genius, and so drag myself back to the computer to cut a much improved draft.