Laziness Chapter I: Meta-Programming

Meta-programming is magic. That is the main reason why we should not use it. There are many dire consequences on the horizon. The same happens with as with design patterns: meta-programming There are states of excitement that all programmers go through. What state are you in? 1. We get to . know them 2. We don’t understand them. 3. We study them thoroughly. 4. We master them. 5. We read that tells us that patterns are everywhere. the bible 6. We thinking they are our brand . abuse them new silver bullet 7. We learn to avoid them. Photo by on Chase Clark Unsplash Magic is at hand When we use meta-programming we speak about the and the . This involves increasing the level of abstraction by speaking the objects in the problem domain. Metalanguage Meta Model above This extra layer allows us to reason and think about the relationship between the entities of reality in a higher level language. In doing so we break the bijection we must use to observe reality since in the real world there are no or , only that we are speaking about. models meta models business entities The one and only software design principle When we are attacking a business problem in real life, it is very difficult for us to justify references to meta entities because such meta entities , which means that we do not remain faithful to the only rule of bijection between our objects and reality. do not exist The metamodel is not present in real world It will be very difficult for us to justify the presence of such objects and such nonexistent responsibilities in the real world. Programmers like to . This is good practice because it allows us to search for generalizations as long as in that real world. extra think about our models they exist Open but not so much One of the most important design principles is the statement belonging to the definition of . The golden rule states that a model must be and . This rule is still true and it is something that we should try to emphasize on our models. However, in many implementations, we find that the way to make these models open is to leave the door open using sub-classing. As an extension implementation, the mechanism seems very robust and very good at first glance, but it generates the only problem we can have in software development: open/closed solid design open for extension closed for modification Coupling: The One and Only Software Designing Problem By linking the definition of , an innocent reference to a class and its subclasses appears, which is the part that could dynamically change . where to get the possible cases (The extension) The algorithm asks the class to interpret certain content. The solution is to delegate to all its subclasses until one of them accepts that they can interpret it and is in charge of continuing with that responsibility. This mechanism is a particular case of the design pattern. Parser Chain of Responsibility However it has several problems: 1. Generates a dependency to the class, which is the entry point for this responsibility. Parser 2. It uses sub-classes with meta-programming, therefore, since there are no direct references, their uses and references will not be evident. 3. As there are no references and uses, no direct refactoring can be carried out, know all their uses and avoid accidental deletions. This stated problem is common to all . The best known and most popular of them is the family and all their derivatives. Classes are global variables and therefore generate coupling and is not the best way to open a model. Let’s see an example of how you can open it declaratively using the : white box frameworks xUnit Open/Closed principle 1. We remove the direct reference to Parser class 2. We generate a dependency to a parsing provider using (Solid’s D). Dependency Injection 3. In different environments (production, testing, configurations) we use different Parsing providers and we do not connect to them belonging to the same hierarchy. 4. We use declarative coupling. We ask these providers to realize the interface. ParseHandling Without references there is no code evolution Photo by on John Doyle Unsplash The most serious problem we have when using meta-programming is having dark references to the classes and methods that will prevent us from all kinds of and therefore will prevent us from growing the code unless we have 100 % coverage. By losing the coverage of all possible cases we might lose some use case that is referenced in an indirect and obscure way and will not be reached by our searches and code refactorings generating undetectable errors in production. refactorings The code should be clean, transparent and have as few meta references as possible that are not reached by someone who can alter that code. Let’s see an example of a dynamic function name construction: $selector = . ->languageCode; Reflection::invokeMethod($selector,$object) 'getLanguage' $this If we are in a client configured in Spanish, the above call will invoke the method; getLanguageEs() The problem with this dark reference is the same as mentioned in the parser example. This method has no references, cannot be refactored, cannot determine who uses it, what is its coverage, etc. In these cases we can avoid these conflicts with an explicit dependency (even using mapping tables or hardwired references) without metaprogramming black magic. The exception defines the rule We have already shown that using meta-programming to refer to our real world entities violating the principle of bijection is a bad practice. So what should we use it for? When we run a simulation we must stay as far away from accidental non-business aspects as possible. Among these aspects are: 1. Persistence 2. Entity serialization 3. Printing or ‘display’ in user interfaces 4. Testing or assertions These problems belong to the orthogonal domain of the computable model and are not particular to any business. Interfering with the responsibilities of an object is a violation of its contract and its responsibilities, therefore instead of adding ‘accidental layers’ of responsibilities we can do it using meta-programming. Not my responsibility Let’s imagine how to model a real-life entity used: Too many accidental responsibilities If we stay true to our one design rule, the first two functions are essential to mastering the problem and the last are not business responsibilities. Therefore they should disappear: Just essential responsabilities Using meta-programming to fulfill such accidental responsibilities for accessing such objects ensures the of your protocol. However it does bring coupling and encapsulation violation issues. purity Some languages incorporate the concept of , which can be used instead of meta-programming. Friend Class The exception to the exception Most testing frameworks use meta-programming techniques to collect items to be tested or test cases. For example: xUnit finds all subclasses of testcase and all functions that start with to build test cases. After many unit tests sooner or later, the need arises to test a method of a problem domain entity. testXXX private In this situation there are two possibilities: 1. Make the previously private method public. 2. Use meta-programming to ‘invoke’ a private method with some reflection mechanism that avoids controls. But to perform 1) we should start to expose accidental behavior that does not belong to the real entity violating the rule of bijection and regarding 2) many languages do not allow it and it is also a bad design practice To solve the dilemma we can check the site created by the great . shoulditestprivatemethods.com Kent Beck The alternative is to think about the reason for testing a private function. The answer is always that the private function does an internal calculation or models an algorithm. { } private function doSomecrazyMathToFindAMagicNumber () // very crazy math To solve the dilemma we leave the private method. We extract the algorithm and test it unitary, achieving concept reification (which surely exists in the domain of the problem) and its possible reuse favoring composition. Happy ending. { CrazyObjectCalculator () -> findMagicNumber (); } private function doSomecrazyMathToFindAMagicNumber () return new and we can test it !! CrazyObjectCalculatorTest extends TestCase { { } } function testFindMagicNumber () //… So we did it in tests. Serialization and persistence can be used with meta-programming because they are not real problems of the domain we are modeling and they should not add “extra behavior” dirtying objects. Photo by on NeONBRAND Unsplash More laziness Unfortunately, meta programming is not the only evil generated by laziness. In this article we will show another problem: Conclusions Laziness Chapter II: Code Wizards Meta-programming is something we should avoid at all costs, instead using abstractions that exist in real world and that we should only go looking for patiently. The search for such abstractions takes a much deeper understanding of the domain than what we came out to obtain, and in the face of the need to learn a new domain, programmers in general, due to laziness, we tend to invent gadgets and mechanisms instead of looking for them in real world. 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.