These are some notes on a String Calculator kata implemented in object-oriented way as a collaboration of entities. By entities we will consider different implementations of the same abstraction that emerged from the different input string formats. This kata implementation is object-oriented and tends to follow the object-oriented behavioral decomposition.

These are some notes on a String Calculator kata implemented in object-oriented way as a collaboration of entities. By entities we will consider different implementations of the same abstraction that emerged from the different input string formats. This kata implementation is object-oriented and tends to follow the object-oriented structural decomposition.

These are some notes on a String Calculator kata implemented in an “object-oriented” way as a single unit of work without state. Why the air-quotes are used? Because it is not true object-oriented ways of doing things, even though the class keyword is used. This kata implementation tends to be sort of procedural, but in a good way.

These are some notes on a String Calculator kata implemented in an “object-oriented” way as a single unit of work with state. Why the air-quotes are used? Because it is not a true object-oriented way of doing things, even though the class keyword and state are used. This kata implementation tends to be sort of procedural.

The big thing about practicing katas is not just to finish them, but the possibility to rethink them while repeating. This works best when you try to rewrite a kata in different paradigms and compare the solutions. Today, I want to talk about a String Calculator kata and its object-oriented implementation. Beyond that, we are going to take a look at decomposition and some object-oriented design principles. Let’s dive into it.

Imagine that you have a task to develop a package or a library. For example, during the last refactoring session, someone mentioned that a piece of functionality should be extracted into a separate package. Or, the company made a decision to open-source a part of internal software or developments. Or, you just have an interesting idea that you want to make public. In all these situations you have to start somewhere. One of the possible ways is to start just from a playground.

I always wondered why in different JavaScript communities and projects people still prefer using functions instead of objects. Of course, we're not talking about projects written in the functional paradigm. What is even more interesting is that in some projects you won’t find any Class keyword, even though this keyword was introduced in JavaScript 10 years ago (in ES6 version). Recently, quite by accident, I had a conversation with a front-end developer who favors functions over classes. It turned out into an interesting discussion that led to a useful experiment, and that is why.

During all my developer’s career I’ve been a big fan of regular expressions. I read books and articles on the topic. I even created a sandbox with common and popular challenges to play around with them. Until recently, I thought I had seen almost all possible tasks and challenges related to regular expressions. However, a few days ago, I came across an interesting case related to case sensitivity which was very new to me.

A few days ago, I released a stip-code library and two plugins (for Vite and for Webpack) that use it. Some people might wonder why someone would even want to use them. Other people might point out that there are plenty of similar solutions. Fair enough, however, I didn’t find a good one and had to write my own.

Some concepts are hard to grasp because of lots of details or because the level of abstraction is too high. Recently, I was asked about the Open-Close principle and how I would explain it. It seems to me, that the simplest explanation is when you show it on the micro level example.