The code has become more compact, but I don't think there was any improvement in readability. In fact, it becomes harder to grasp what this method is doing because:

1. You now have a break in mental context - you have to travel mentally to methods calcOcKeyNum and addToObject to check what they do (it's still not obvious.)

2. The addToObject method is not self-contained, which makes it even harder to grasp its logic.

Hi!

I would prefer #1.

Yeah, I think a lot about it as well. All the refactoring is only needed for us, humans. If AI will ever learn to code, I doubt it ever needs to refactor anything at all, it will comprehend the ugly code just fine: "it's good as long as it works".

Hi!

To be honest with you, I don't see a reason to change something in it. Yes, it may look a little messy, but so does the format of the input. Without changing the input and possibly, the output as well, this method wouldn't become much better. If there are others similar to this one, then maybe it's worth making some sort of data mapping. Otherwise, you would see similar lines in my own code.

Thank you!

In my experience, the "modern OOP" is all about pushing the ugly stuff under the rug (to the client code). For example, a framework or a library that you're using might be a pinnacle of design, but it requires you to write a ton of ugly configurations to start the thing. It's generally unavoidable to have this sort of code somewhere, and the most that you can do is to move it to a single place and make it as small as possible.

Hi Rosa!

Let me start by complimenting you on the good question! Not only that, your question contains a perfect answer by itself!

Creating subclasses that include some sort of customization is indeed one of the ways to solve this problem. Other commonly used options are:

1. Provide a way to pass a generic configuration object into the creation method. Very easy in dynamically typed languages, but also doable in static languages.

2. Creation method can fetch configuration from some centralized place.

3. Remember that it's all just code; you can change all of this to suit your needs, there's no "pattern dogma". If none of the above fits nicely into your code, you can simply evolve your Factory Method into something else, such as the Builder or Dependency Injection patterns: you pass an already built product into the creation method. In this case, the Creator's mission may be to cast the passed object into the desired type (because you can't narrow down the parameter type in a subclass, but you can narrow down the resulting type, according to LSP).

Hi!

Thanks for asking! I used OmniGraffle (sadly, only available on macOS) with heavily customized UML stencils for most diagrams. The illustrations (comic strips, etc.) were initially drawn by hand and then vectorized in Inkscape.

Best of luck!

Вітаю, Євгене!

Переліку змін я не веду, але якихось глобальних змін не було. Все що було, це виправлення помилок.

Hi!

There's no time limit, you can lear at your own pace.

Please let me know if you have any further questions.