你好！

抱歉，这本书没有有关此设计模式的信息。

Hi!

Thanks for your offer, I appreciate it! I'll let you know if/when we're ready to start with this project. For now, there's a lot of other stuff has to be done first.

Hi Tomasz!

To be 100% honest with you, the reaction of your team lead to your asserts in the production code will solely depend on his/her expertise and the project's code style conventions. Asserts in code are indeed not very common. I've seen assertions in non-unit-test code quite a few times in various projects over the years.

Usually, they are placed in such a way, that triggering them would mean that something that's very wrong happened to the project. Sure, you can replace them with exceptions, but that'll be just a waste of code for something that does the same thing. Personally, I'd use them if a simple assertion in code would spare me a very sophisticated unit-test that involves heavy mocking. Depending on the language you're working with, it's also possible to turn off assertions when building project for production.

Hi Carlos!

Thanks for the idea! This is definitely an important task and it's in my plans. I have to tackle higher priority stuff first, though.

Okay, I've rewritten it like this:

**Command** is a behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation lets you pass requests as a method arguments, delay or queue a request's execution, and support undoable operations.

Hi John!

Thanks for your question. I think I understand the reason for the confusion. This paragraph means that after wrapping the request in a command object, you can then pass this command object to any methods (on other objects) that deal with requests. Since all of the commands implement the same interface, you can pass different kinds of commands (and therefore, requests) to the said methods.

I'll see if I can rewrite this paragraph for a clearer understanding.

Спасибо за предложение. Да, это уже давно в планах. Хочу совместить это с другими работами по фронтенду, пока никак до этого не доберусь. Но всё же это когда-то случится :)

Hi Kent!

In simple terms, a delegate is an object that helps the other object to do some stuff. The original object "delegates" the work to a delegate. In various sources, the term delegate might be loaded with additional meaning (you can read more about this on wiki), but in my course, it simply means passing some work to another object.

Please let me know if you have any further questions.

Дякую вам за відгуки, пані та панове! Дуже радий, що вам усе сподобалося.

Thanks for the idea, Bryan! I believe this can be a fruitful area for someone to write a thing about. I'm afraid I lack decent expertise in the Kubernetes fields to write something of my own.