The One and Only Software Design Principle

If we build our entire paradigm on a single rule, we can keep it simple and make excellent models. Being minimalist and being axiomatic means we can derive a set of rules from a single definition. If we build our entire paradigm over one single rule we can and make excellent models and thus excellent software. Keep It Simple, Stupid One of the most underrated quality attributes on software is the kind of being predictable. . but being predictable is almost nowhere on the top five design priorities. We are taught at the university and books that software should be fast, reliable, robust, secure, etc We are going to make an exercise on object-oriented software design by stating just one principle: Each domain object must be represented by a single object in our computable model and vice versa. The relationship between model objects and entities of real world is 1: 1 We can see the justification of this model in this : article We will then try to derive design rules and heuristics from that axiom, of course without contradicting it. The Problem We will see that most of the language implementations used in the industry ignore this rule and this causes enormous problems. Invoking problems that arose in the construction of software 3 or 4 decades ago and that they almost no longer exist or are present in a few domains we continue to make decisions like monkeys that beat others without knowing the reason for such behavior. Models to the rescue When building models of any kind we want to be able to simulate the conditions that occur in the observed real world so that we can follow each element of interest in our simulation and stimulate it to observe the changes in the same way that they happen in the real world. Meteorologists make mathematical models to predict and anticipate the behavior of climate and most scientific disciplines are based on these simulations. With the rise of machine learning, we build black-box models to predict behaviors in real life. The importance of bijection In the domain of software and under the paradigm of objects we will always have one and only one object representing a real-world entity. Let’s try to prove by the absurd what would happen if we did not comply with the principles of being a bijection. Common cases in the industry that violate bijection Case 1) We have an object in our computable model to represent more than one real-world entity. For example, many programming languages model algebraic measures using only scalar magnitude. Then we can represent and (two completely different entities in the real world) by a single object ( ) and we could add them together obtaining that in our model the representing ) the (representing ) is equal to the (representing who knows what). 10 meters 10 inches the number 10 number 10 10 meters number 10 10 inches number 20 This generates problems not always captured on time. Because it is a semantic fault, the error usually occurs long after the failure as in the famous case of the Mars Climate Orbiter. The probe exploded by mixing different units of measurement. Case 2) Our computable model represents the same real world entity with two objects. Suppose we have in our observable real world an athlete who competes in one discipline but who is also a judge in another athletic discipline. John Smith A single person in real world should be a single object in our computable model. We need to model just the minimum behavior to fulfill our partial simulation. If we have two different objects (a and a ) that represent , we will sooner or later have inconsistencies by wanting to assign some responsibility to one of the two and not see it reflected in the other. competitor judge Jane Doe To solve these types of problems we must stop seeing entities as , think of them as and understand that they are the fulfilling depending on the context in which they are interacting. data structures with attributes objects same object different roles We can even decide not not represent but his roles on the simulation. Jane Case 3) A can be represented as an object (with some properties regarding address, balance etc) or by a (with responsibility such as receiving transactions, writing to a blockchain etc) but its clear for someone who is not in software business they are related to the same concept. So the bijection must be held. bitcoin wallet anemic functional one Case 4) In most modern object programming languages, a date can be constructed by creating it from its day, month and year. We all learned that a can be created and that most of the languages will gently return a valid object (probably ). But this disguised as a benefit is nothing but , generating a to the design decision made by the programming language and hiding a sure error in the data load. November 31th, 2020 December 1st, 2020 error hiding coupling dependency The error will appear later on, running a nightly batch of processing these dates far from the root cause violating the principle. Coupling: The One and Only Software Designing Problem Fail Fast Fail Fast Philosophy, Explained Conclusions In this article, we define the only axiomatic design rule that we will respect no matter what by justifying the problems that come with not respecting it and laying the foundations for future definitions derived from it. Acknowledgements Part of the ideas in this article were developed together with and all the members of Software Engineering Staff at Hernan Wilkinson Universidad de Buenos Aires. Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article.