¿Cómo utilizas la programación defensiva en tu diseño orientado a objetos?

While thinking about defensive programming and the governing principles, I think its also important to underscore the secure by default principles: separation of privileges, zero trust, principles of least privileges. While its difficult to think about all of this during writing code, it is most effective to think about this during threat modeling exercises

1.Never assume that inputs, data, or external dependencies will behave as expected. 2.Detect errors and failures as early as possible in the code and handle them explicitly. 3.Gracefully handle errors and exceptions to prevent crashes or unexpected behaviour. 4.Employ defensive programming techniques such as input validation, boundary checks, data validation, type checking, and error handling to guard against unexpected inputs, invalid states, and runtime errors. 5.Write code that is simple, clear, and easy to understand, maintain, and debug.

Although the topic itself says many true things, there is one that always get my attention: Contracts should be used to define interfaces. Yet, if we read many documentations, interface are contracts. So, we should use contracts to define contracts? Seems that there is some kind of miscommunication there. Saying that we should make it clear any expected constraints that the programming language itself cannot enforce would make much more sense. Yet, choosing a programming language that has better support to enforcing things would be even better. .

in my opinion several strategies can be employed: 1.Input Validation: Validate inputs to methods and constructors to ensure they meet expected criteria. 2.Encapsulation: Encapsulate internal state and behavior of objects to control access to data and prevent unintended modifications. 3.Error Handling: Implement comprehensive error handling mechanisms to detect and handle unexpected conditions gracefully. 4.Preconditions and Postconditions 5.Fail-Fast Mechanisms 6.Defensive Copying 7.Design by Contract 8.Testing: Implement thorough unit tests to verify the correctness of individual components

Most of the points are true, except for the part about readability. A code that uses defensive programming might not have bugs and so, might never need to be debugged, yet reading the code might become harder because all the extra code for the defense. I am not saying it doesn't need to be done, I am just pointing out a reality. Code that doesn't do null checks might look much easier to read to somebody that just wants to learn how to program something simple, yet that code will be much more prone to bugs.

Exceptions (are evil) An exception is a side effect! Why have programmers banished the 'goto' but not the throw? (or a 'null' return value); instead, methods should return a 'Result'. - A throw disrupts normal program flow. - A throw makes a function dishonest if its signature suggests a return value - A throw makes a function leaky as one must look inside to know what is thrown. One must travel in code to understand all paths between throw and catch to understand exception handling. To remove either changes behavior!

Input validation is just the beginning. We must keep our objects immutable and always in a valid state with an appropriate level of encapsulation. The above, combined with a set of unit tests that validate only observable behaviors without attaching to implementation details, is a good example of defensive programming.

Defensive programming may be useful in situations like when you change the structure of your database entities because of the new requirements of your business logic and you have to perform some operations that is more difficult and error prone to do with a set of database update statements.

Adding comments to code should not be an alternative to writing clear and readable code with well-defined function and variable names. A clean and readable code can be well understood by experienced developers at the first read without even needing a lot of comments in code.

Comments (are lies) Comments, over time, are lies. As programmers are untrustworthy, comments are not trustworthy to reflect changes. "No comment is better than a comment that is no longer true." Comments are often warning signs that code is too complex or has improper dependencies. The urge to write comments hints at a failure to express or conceptualize an idea in code--intent. Note: to the exclusion of a 'summary' atop a function definition, which is more of a narrative than a comment. Albeit charming, they too are untrustworthy.

Be careful regarding storing references to mutable objects that can be modified from the outside. For example, if you write a constructor or factory method for a class Interval with two DateTime's as arguments, then you might write some precondition code that throws an exception if the start would be after the end, and otherwise store references to the DateTimes. But if they are mutable (for example Java's Date class has a setDate method) then that would not be enough to make sure the invariant (something that always should be true, e.g the start is always before the end) is never violated. You can instead clone the DateTime's before storing them, and also clone them if the class provides getters such as getStartDate and getEndDate.

Proper type checking is vital in defensive coding, along with proper encapsulation. Focusing on encapsulating valuable domain logic rather than falling into the trap of primitive obsession is key to writing clear and robust code.

- exception handling can be fun if they are exported to cloud vendor like rapid7 and analysed. OSS also available like elk, Graf Ana and etc - exceptions bubble to top so graceful message can be displayed from root scope handler and granular exception can be logged - remember not to silence an exception instead handle the most granular condition like null value due to attribute error and bubble up others. So the program will break and reason will be logged and issue can be fixed. - exception handling and logging can be a overhead but tech standard like open-telemetry is the new norm for tracing all micro services via one request. Error handling can be a hassle if one of many services is failing and tracing can save the day

My impression is that most of these articles say the same thing independently of the topic. Documentation, best practices, making code more readable maintainable and easy to debug, unit-tests... well, those are all desirable, but it doesn't seem to focus on the main topic: Defensive programming. As I see, and as I read on Wikipedia, it seems to be related to actual attacks. It is not about "something can go wrong" but that attackers would do everything possible so things will go wrong. That's why validating inputs is important. But, some attacks are done at the serialization layer, so, it doesn't matter if an exposed service method does the right validations when it is invoked, things might fail before reaching there.

Una cosa que he notado es que la programación defensiva ayuda a identificar comportamientos indeseados de forma temprana haciendo que la ejecución del resto del programa sea mucho mas limpia y clara. Por ejemplo, si necesitas validar ciertos parámetros para luego guardarlos en base de datos estructura tu código de esta manera : 1- Valida Todo al inicio 2- Devuelve errores o excepciones temprano si algo no cumple las reglas de validación. 3- Evita múltiples caminos para reducir la complejidad del código siempre que puedas 4- Guarda en Base de Datos 5- Devuelve una respuesta sobre el éxito de la operación a los niveles superiores si estos dependen de ella Además de esto, registra Logs de los eventos allí donde suceden y analísalos 😉.