Before we get our hands dirty with the first algorithmic challenge, let's take a moment to discuss the difference between algorithmic challenge code and application code. We will also take a brief look at the rules of Object Calisthenics and how they can guide the design of classes in an object-oriented way.

Changes Drive the Design

Algorithmic challenge code and application code serve different purposes and thus have different characteristics.

Algorithmic challenge code is typically written once to solve a specific, well-defined problem. It is often self-contained, meaning it doesn't rely on external systems or services. The primary goal is to find the most efficient solution to the problem, and once the problem is solved, the code doesn't need to change. Moreover, this code is not going to be read by anyone else, so it doesn't need to be particularly readable or maintainable. There's no need to understand that code while trying to figure out what changes should be made to get the new desired behavior. This is why algorithmic code can often be more direct, less abstract and kind of "cryptic" at times.

On the other hand, application code is designed to be part of a larger system and to interact with various components of that system. It needs to be flexible and adaptable to accommodate changes in requirements or system design. Most of that code is going to be read by other developers trying to understand how the system works and how to modify it. This is where Object-Oriented Programming (OOP) comes in. OOP allows developers to encapsulate data and behavior into objects, making the code more modular, reusable, and easier to change. This encapsulation also makes it easier to reason about the code, as each object has a well-defined goal, responsibility and interface, hiding its internal state and implementation.

In summary, while algorithmic challenge code is focused on solving a specific problem efficiently and doesn't need to change once the problem is solved, application code is designed to be part of a larger, evolving system and thus needs to be written in a way that makes it easy to adapt and modify.

Guiding the Design with Object Calisthenics Rules

So, we don't need to consider future changes when solving algorithmic challenges, because we don't have to change the code once the problem is solved. But how can we derive the design of our classes in an object-oriented way without further specific requirements or anticipated changes?

This is the unique challenge of transforming algorithmic code into an object-oriented form. We have to have some kind of guidelines to follow, some kind of rules to guide us in the design process.

This is where the rules of Object Calisthenics come into play. These rules provide a set of guidelines that can help shape the design of classes in an object-oriented way, even in the absence of specific requirements or anticipated changes. By adhering to these rules, we can transform our algorithmic code into a more object-oriented form, making it more modular, flexible, and maintainable.

What is that Object Calisthenics anyway?

Object Calisthenics is a set of coding practices that guide developers in improving their code through the principles of object-oriented programming (OOP). The term "calisthenics" refers to exercises designed to improve one's physical health, strength, and flexibility. Similarly, Object Calisthenics exercises are designed to improve the health, strength, and flexibility of your code. They help to ensure that the code is easy to read, maintain, and extend, which is crucial for a successful collaborative development of a constantly evolving system.

Here are the rules of Object Calisthenics along with their brief descriptions:

1. Only One Level Of Indentation Per Method: This rule helps to keep methods small and focused on a single task.

2. Don’t Use The ELSE Keyword: This encourages the use of polymorphism and prevents complex conditional logic.

3. Wrap All Primitives And Strings: This promotes the use of objects that have behavior, rather than primitive types and strings that do not.

4. First Class Collections: This rule suggests that any class that contains a collection should contain no other member variables.

5. One Dot Per Line: This rule encourages the use of well-encapsulated objects that expose behavior and hide data.

6. Don’t Abbreviate: This rule promotes clarity through explicitness.

7. Keep All Entities Small: This rule suggests that large classes, methods, and other entities should be broken down into smaller, more manageable pieces.

8. No Classes With More Than Two Instance Variables: This rule encourages classes to be focused on a single responsibility.

9. No Getters/Setters/Properties: This rule promotes the use of objects that expose behavior, not data.

You can find more detailed explanations of these rules online, for example, here. I'll also try to explain those rules in the context of our exercises as we go along.

Conclusion

In conclusion, while algorithmic challenge code focuses on solving specific problems efficiently without the need for future modifications, application code requires a more robust and flexible design to accommodate ongoing changes. Object Calisthenics provides a valuable set of rules that guide developers in shaping their code according to object-oriented principles. By adhering to these rules, developers can ensure their code is modular, readable, and maintainable, ultimately leading to a healthier and more adaptable codebase. As we dive into our exercises, applying these practices will help us transform our algorithmic solutions into well-designed, object-oriented code.