Object-oriented programming on CheckIO

For a long time, the CheckIO coding challenges were solved solely by writing ordinary functions. But recently we've decided to expand the field of action and began to add tasks that require using the object-oriented programming.

We've also published 4 articles, where we went through several design patterns. You can practice their usage by solving the tasks created specially for them. By learning to apply these patterns, you can greatly facilitate the process of writing code, as well as interacting with other developers.

Let's remember which patterns were examined and with what tasks you can practice OOP.

Articles and missions

Part 1 - In this article we've looked at the Abstract Factory and Strategy patterns. The first one is convenient for situations when the program already uses the "factory method" but the next changes involve the introduction of new types of products, or when the program logic must work with different types of related products regardless of the specific product classes. The Strategy is suitable for situations in which it's necessary to define various options of interaction with the input data, and this pattern allows you to configure the switching between options both in the automatic mode (when the chosen method depends on the input data itself) and in manual (when the user himself chooses the necessary strategy from the available ones).

You can use the Abstract Factory pattern for the "Army Units" mission.

And the Strategy pattern can help you to solve the "Geometry Figures" mission.

Part 2 - This article was devoted to the Observer and Mediator patterns. The Observer is convenient when there's a need to create a subscription mechanism that allows one object to monitor and respond to events occurring in other objects. The Mediator is often used in situations where you need to reduce the connection of multiple classes with each other (for example, when you can't reuse a class because it depends on a lot of other classes or when you have to create multiple component subclasses to use the same components in different contexts).

In the "Party Invitations" mission you'll need to send out the party invitations to your friends, and the Observer pattern will do just fine.

By using the Mediator pattern to solve the "Dialogues" mission you can create a simple version of a messenger.

Part 3 - In the third article we've looked at the Memento and Bridge patterns. The first one helps a lot when it's necessary to save and restore the objects past states without revealing the details of their implementation. The second allows you to divide one or more classes into two separate hierarchies - abstraction and implementation, allowing you to change them independently, which is also necessary in certain situations.

The Memento pattern will be very useful in creating a text editor with the ability to remember the text state and restore the previous versions. You can come to appreciate this in the "Text Editor" mission.

The most convenient way of solving the "Microwave Ovens" mission is by using the Bridge pattern.

Part 4 - In the last article of the series on patterns we've described the State and Interpreter. The State can be effectively used in situations where you have an object whose behavior varies drastically depending on the internal state, and there are many types of states, and their code often changes, and also when the class code contains a lot of large, similar to each other, conditional statements, which select the behavior depending on the current values ​​of the class fields. The Interpreter, also known as the Little (Small) Language, allows you to solve a frequently occurring but subject to change task and is effective for any set of the related data that can be described as a certain "language".

The "Multicolored Lamp" mission can be solved in many ways, but the most effective will be by using the State pattern.

The Interpreter pattern will certainly be of great help while creating your own "Hacker Language".

A new series of tasks

One of our other developments is a series of tasks dedicated to the subjects of war, fantasy and the Middle Ages. This is the story of a brave knight - Sir Ronald and his opponent - the warrior Umberte. Everything begins as an ordinary duel, but the longer the fight lasts, the more troops are pulled from the both sides.

In the first mission, The Warriors, you'll need to determine the winner in the 1x1 duel. In the second mission, the "Army Battles", it'll be necessary to evaluate the result of the battle between two armies, in which the soldiers fight each other one by one until the last one is eliminated. Then, in "The Defenders", "The Vampires", "The Lancers", and "The Healers" missions, the new types of soldiers will be gradually added, with each of them having a special effect - the defender will reduce the received damage, the vampire can suck out life and heal when dealing damage, the lancer can attack two enemy soldiers at once, and the healer can heal his allies.

In the next mission, the "Straight Fight", you'll have the opportunity to conduct fights between the armies in an alternative way - wall to wall. After that, in "The Weapons" mission, you can equip all soldiers with better weapons which will affect their parameters. Finally, in "The Warlords" mission, you'll be able to add a key figure - the commander, who can set the strategy and rearrange the soldiers so that they fight as effectively as possible.

All missions are related, so we recommend starting with the very first one - "The Warriors". When you successfully solve it, click "Next mission", and you'll be redirected to the next mission in this series. Your solution will also be transferred, so you won't have to write everything from scratch, just add code that takes into account the conditions of the current task.

Conclusion

We're planning to continue expanding the scope of OOP tasks, adding both the individual missions and entire series with connected storylines. If you have interesting ideas that you'd like to see implemented in the missions, write about them and we'll implement them in the code.