If you've worked with developing software of any real complexity, you've probably come across a library or tool that does code generation. Instead of writing all the boring boiler-plate stuff yourself, you maybe throw a little configuration at the system and let it generate all those classes for you. I'd argue that, in most cases, that sort of thing is a code smell- it's not in and of itself bad, but it hints as missed abstractions. There's probably a general way to represent what you want to represent without generating a big pile of classes. The question is: is the additional abstraction worth it, or should you just generate code to get it done?

Russell was recently browsing the documentation for Amazon Web Services. The Java SDK allows you to send requests to AWS to automate things in their cloud. When you send a request, you need an AmazonWebServiceRequest object. Now, AmazonWebServiceRequest is itself an abstract class, so we need to send a concrete implementation, specific to the operation we want to perform. That means it's going to be one of:

AbortDocumentVersionUploadRequest, AbortEnvironmentUpdateRequest, AbortMultipartUploadRequest, AbortMultipartUploadRequest, 
AbortVaultLockRequest, AbstractPutObjectRequest, AcceptCertificateTransferRequest, AcceptDirectConnectGatewayAssociationProposalRequest, 
AcceptDomainTransferFromAnotherAwsAccountRequest, AcceptGrantRequest, AcceptHandshakeRequest, AcceptInboundCrossClusterSearchConnectionRequest, 
AcceptInputDeviceTransferRequest, AcceptInvitationRequest,
…
VerifySoftwareTokenRequest, VerifyTrustRequest, VerifyUserAttributeRequest, ViewBillingRequest, 
VoteOnProposalRequest, WithdrawByoipCidrRequest, WithdrawByoipCidrRequest, WriteRecordsRequest

I skipped a… few thousand of them in the middle there. You can get them all on the docs page. If you dig into any of the concrete implementations, they're all tagged as @Generated. I'm sure that there are more convenient methods which wrap around this, and that your average SDK user is never going to need to directly interact with any of these classes, but when you see a wall of generated classes, you can't help but wonder if this is the best approach. At a certain level, SDKs are meant to be understood by humans, and if you have about 9,000 auto-generated types, maybe you've lost the plot just a little bit.

And if you're worried about how you handle the response, don't be. Each of these request classes has a Result version as well. Well, not each of them- there's only 8,704 Result types. Now that's efficient.

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.