To mutate is to evolve. It was proposed by Sir Charles Darwin and we use it in the software industry. But how mutable should software be? Since the very beginning of stored program concept, we learned that software is Programs + Data. It is clear that without data there is no software. In object-oriented programming we build models that evolve over time, emulating the knowledge we learn by observing the reality we are representing. What is (wrong with) software? However, we manipulate and abuse those changes uncontrollably, violating the only important design principle by generating incomplete (and therefore invalid) representations and propagating the ripple effect with our changes. The One and Only Software Design Principle In the functional paradigm, this is elegantly achieved by directly forbidding mutations. We can be (a little) less drastic. Returning to the essential The great gave us a few thoughts. Among others, he told us about he taught us to be suspicious of and educated us in the separation of Fred Brooks The myth of pregnant women, silver bullets accidental vs. essential complexity. The essence of an entity of reality is that which makes it be itself and not another. https://app.hackernoon.com/stats/there-are-no-silver-bullets-for-this-werewolf-2t213woi The entity’s accident happens due to temporary situations that despite changing object behavior do not prevent us from noticing we are watching  the same entity even though it evolves as we  do not bathe twice in the same river. Photo by Alexander McFeron on Unsplash Being true to our bijection, in our computable model we should be able to distinguish when an object changes in terms of the accidental and prohibit all essential changes (because they would violate that bijection which is our only principle). Objects should know how to defend themselves against invalid representations. They are the powers against mutants. Photo by Joey Nicotra on Unsplash Is data ok ? In most countries, an invoice is a written and unchangeable document. Altering it has criminal consequences similar to what happens with a transaction in a blockchain chain or a ledger. In this problem domain, immutability is a rule, therefore our simulations must respect it. However, those of us who have worked in economic, financial or banking domains have built systems that violate these rules in a systematic way with some excuse related to or (our favorites). As a personal anecdote, in one of my first jobs for a large international bank, we modeled financial transactions with an attribute that we had as a Boolean until we made sure that the transaction was indeed a valid and actionable transaction. This brought us multiple coupling problems on multiple occasions. laziness performance isDataOK flag Coupling: The One and Only Software Designing Problem Besides, many of those fields remained with null values ​​(instead of modeling the incompleteness or indefiniteness of the data), so we had to spread the code with multiple controls by to validate that some of the data against nulls. ifs NULL: The Billion Dollar Mistake Thinking about how to build a solution to the problem we were solving at the time, I found the answer on our only axiom: Bijection one by one with reality. Let’s revisit our 90s code: { $party; $counterparty; $amount; $date; $isDataOK = ;
} class Movement public public public public public false A hollow class with a lot of attributes and no encapsulation but with a ( ) should when it could be safely used. flag isDataOK Let’s start by hiding the decision to know when it is an actionable movement. { { !is_null( ->party) && !is_null( ->counterparty) && !is_null( ->amount) && !is_null( ->isDataOK);
    }
} class Movement : function isDataOK () bool return $this $this $this $this Then let’s go on encapsulating the movement’s attributes: $party; { ->party();
} { ->party = $aParty;
}
..... private function getParty () return $this function setParty ($aParty) $this This movement is mutable (despite not being so in the real world). We must ensure that it behaves as our observed entity. { $party; $counterparty; $amount $date;
} { ->party = $aParty; ->counterparty = $aCounterParty; ->amount = $anAmount; ->date = aDate;
    }
} final class Movement private private private private function __construct ($aParty, $aCounterParty, $anAmount, $aDate) $this $this $this $this Simple, elegant, immutable, without , always valid, without setters or getters. dataOk Movement is valid from inception, just as it happens in the real world. Now let's assume that a business rule prevents us from making movements between the same party and counterparty (this happens in the real world). In our first version this control would be impossible. In the immutable version we only represent real situations, it will be enough to prevent the construction of these objects. { ($aParty == $aCounterParty) { PartyAndCounterpartyCannotBeTheSameException($aParty, $aCounterParty);
    } ->party = $aParty; ->counterparty = $aCounterParty; ->amount = $anAmount; ->date = aDate;
} function __construct ($aParty, $aCounterParty, $anAmount, $aDate) if throw new $this $this $this $this Times are changing We are going to continue the previous example focusing on the date on which said the transaction was made. In the real world, a date represents a day on an arbitrary calendar. If we create a movement in bitcoins for and we recreate it in our computable model we will have something like this. May 12, 2020’s halving event $halvingTransaction = Movement($wallet, $destination, $bitcoins, Date( , , )); new 12 5 2020 But this violates our unique design principle of maintaining a bijection with the real world. Let’s be loyal to our single rule. $day12 = Day( );
$year2020 = Year( );
$may2020 = YearMonth( , $year2020);
$halvingDay = Date($day12, $may2020);
$halvingTransaction = Movement($wallet, $destination, $bitcoins, $halvingDay); new 12 new 2020 new 5 new new We model reality’s entities such as a , forgetting about arbitrary implementations with because bijection and declarativity are more important than performance and laziness. day of a month, a calendar year, and a date integers Let us dwell for a minute on the mutability of a date. One hopes that a date will never mutate because it does not do so in the real world. No non-computer person would ever think of changing a date. Now let us analyze by the method of reduction to the absurd what would happen if we allow a date to change. Our accredited transaction on the day of halving knows its imputation date. If it changes internally all consecutive blockchains should be recalculated and this is expressly prohibited by the financial domain. It is clear that the date should never mutate. Is it crystal clear for everybody that a date should not mutate? Let’s review the in the most widely used languages ​​in today’s industry. Date class : Date is a struct. Go : Mutable (deprecated). Java : Mutable with setters abuse. PHP : Mutable (All attributes are public on Python). Python : Mutable. Swift Date problem’s domain is probably one of the oldest and best known to humanity. The excuse that these are being deprecated speaks about poor initial design in most modern languages. getters Possible solutions A possible attack is to reverse the burden of proof. Objects are unless otherwise stated. completely immutable Should they evolve they must always do so in their aspects. Never in their . This change should not be coupled to all the other objects that use it. accidental essence Conclusions If an object is complete since its creation, it will always be able to answer to messages. An object must correctly represent the entity since its inception. If we work in a concurrent environment it is essential that the objects are always valid. An object must be immutable if the entity it represents is immutable. Most entities are immutable. These rules keep the model consistently consistent with representation. As a corollary of the demonstration by the absurd we can derive a series of rules: Corollary 1: Objects must be complete since their creation. Corollary 2: Setters must not exist. Nude Models - Part I : Setters Corollary 3: Getters should not exist (unless they exist in the real world and then the bijection is valid). It is not the responsibility of any reality entity to reply to a message. getXXX() 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. This article was also published in Spanish.

Chain

Fail Fast Philosophy, Explained 

NULL: The Billion Dollar Mistake

Buy My Book

Is it Crystal Clear for Everybody That a Date Should Not Mutate?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Predictions About the Future of Finance

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

What No One Told Me About Being a Product Manager at an Early Stage Startup

10 Predictions About the Future of Finance

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

What No One Told Me About Being a Product Manager at an Early Stage Startup

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps