Pathologies of Inquisitive Code
Objects that are not assertive are by default inquisitive. They are either inquisitive or they are mute. They don’t interact with the outside word at all. If an object interacts with other objects, the real question with regard to assertiveness is, “Who’s in charge?” One object can delegate a task to another object but still …
Continue reading “Pathologies of Inquisitive Code”
Read MoreQuality Code is Assertive
The next code quality in this series of posts, the “A” in CLEAN, stands for assertive. I don’t hear a lot of people talking about it but I think it’s an important code quality. We want the software we write to be assertive, to be in charge of its own state. We want objects to …
Continue reading “Quality Code is Assertive”
Read MoreEncapsulation and Testability
Poorly encapsulated software is hard to test because without clear boundaries, what we actually test becomes significantly larger than what we need to test. This makes our tests run slower and it also makes them brittle so our tests are harder to maintain. When code is unencapsulated, it can be hard to lock down behaviors …
Continue reading “Encapsulation and Testability”
Read MorePathologies of Unencapsulated Code
Unencapsulated code is code that exposes its implementation or references how it does something. This can happen in subtle ways, so we have to be careful to create strong contracts through our method signatures. Poorly encapsulated code is very difficult to work with. It can quickly sprout new bugs at the slightest change. Lack of …
Continue reading “Pathologies of Unencapsulated Code”
Read More