APIs: Our Legacy From Flawed 1960’s Thinking
Object-Oriented Programming and Design principles have now existed for over 50 years, so it seems odd that, no one's noticed its substantial flaw.
Join the DZone community and get the full member experience.Join For Free
Object-Oriented Programming and Design principles have now existed for over 50 years, so it seems odd that apparently, no one has noticed the substantial flaw in Object-Oriented Design that has existed since the very beginning. We are instead told that Object-Oriented (OO) Design principals have won the day, as they provide a programmatic mirror image of the real-world scenarios they are intended to reflect. If we look a little deeper, OO Design is in fact completely detached from the world that it is intended to model. Whilst it is obviously true that the world consists of objects — known and unknown, real and abstract — the unimaginable flaw in OO Design fundamentals that seems to remain undetected until this day is that calling objects can never have complete mastery of the Interfaces of the objects they call: objects can only ever be masters of their own Interface — of themselves.
Let’s imagine a Customer Object in negotiations with a SalesContact Object, in any given IT Landscape. OO Design asks us to pretend that the Customer Object has perfect mastery of the SalesContact Object Interface, and therefore knows exactly how to call the relevant RequestQuotation method of the SalesContact Object: having already guessed at the name of that method, its latest publicly-available version, and based upon the false hope that the definition of the RequestQuotation method will not change over time. The obvious reality is that the Customer Object can only guess at the Interface of the SalesContact Object, and hope that this Interface does not change in the short-term (e.g. as the product range offered by the SalesContact becomes more developed, and therefore more complex). Add to this the fact that the very same Customer Object may need to exchange with several different SalesContact Objects in several different departments, not all using the same Interface Version or even the same Interface — the same API — and we must consider that the OO Design philosophy, as it stands today, is massively flawed.
And what if we considered the same example of a Customer Object in negotiations with a SalesContact Object, using the real-world principles of 'Event-Driven Architecture' (EDA)? Under the EDA philosophy, the Customer Object could raise an event called ‘Quotation.Requested’ — using the Event Payload format and version of its choice (for the Customer Object is master only of itself) — and any SalesContact Object(s) that chose to subscribe to the corresponding ('Requested') Topic — regardless of the internal or external network in which it resides — will receive this Event Payload from the Event Broker, and will act — irrespective of the technology or version upon which it is based — in the manner of its choosing: the SalesContact Object is master only of itself, as per the real-world.
If we consider a scenario of 4 distinct Backend systems — with up to 4 distinct API versions — we could imagine a situation in the example just given where the first 3 SalesContact Objects choose to completely ignore this latest ‘Quotation.Requested’ Event, having decided that their department (/host system) is not concerned, but where the 4th SalesContact Object might instead choose to create a Quotation upon the basis of the received ‘Quotation.Requested’ Event Payload; once completed, to trigger a ‘Quotation.Created’ Event containing the newly committed data. The Customer Object would then be immediately informed by the same Event Broker, at which point in time, it would process the new ‘Quotation.Created’ Event exactly as it chooses (e.g., perhaps another quotation has already been accepted, given the 4th SalesContact Object was unavailable during several hours; as happens in the real-world). For more information, see 'Requested Event Pattern.'
As an important contrast with historic OO/API principles, what if the point is made that any ‘Quotation.Requested’ Event Payload could be packaged — at very little cost — to include as many as 10 distinct (JSON) Payload formats/versions, within a single Event Payload? Given that the publishing Customer Object does not and cannot possibly have complete mastery of the relevant API(s) of the subscribed SalesContact Object(s), it is in reality for each subscribed SalesContact Object/Software Component to decide for itself which of the embedded versions of received Event Payloads it is capable of processing; simply ignoring the others. So what will be the impact on the — unchanged — SalesContact subscriber(s) when the Customer Object is eventually upgraded to include the most recent 'Requested' Payload formats (and it will be)? There will be no impact whatsoever! They will process any received ‘Quotation.Requested’ Events to which they subscribed exactly as they did before, ignoring the newest Event Payload versions and formats; until they themselves are upgraded to support the latest versions.
Another important contrast with historic API — i.e., REST — fundamentals is that 'JSON-friendly' GraphQL requests can be simultaneously embedded as one of the included Payload formats, thereby allowing the combination of several distinct request formats in a single 'Requested' Event Payload. The day that one of the SalesContact subscribers is upgraded to serve GraphQL requests, it can switch seamlessly to using this latest request format; something the Customer Object ought never to have to concern itself with.
Client Objects should no longer be asked to have perfect knowledge of the Interface/API of each and every Object/Service upon which they depend, or to couple their own evolution with the completely unrelated update schedules of called Objects/Services, but instead to focus only upon themselves; as per the real world. Somewhat surprisingly, this utopia can be easily achieved via the use of a technique I call 'Version-Stacking'. For details, see: ‘Event-Oriented Architecture’ Manifesto for Distributed Enterprise Applications.
Published at DZone with permission of Cameron HUNT. See the original article here.
Opinions expressed by DZone contributors are their own.