Your comments

Hi Syahriga!

Thanks for asking. Let me answer your questions by simply quoting parts of the article for starters:

> Why using it just to remove comment?

Make these assumptions obvious by adding corresponding assertions. As with type hinting in method parameters, these assertions can act as live documentation for your code.

> What is your consideration on using it?

If the exception can be caused by actions of the user or system and you can handle the exception. On the other hand, ordinary unnamed and unhandled exceptions are basically equivalent to simple assertions – you don’t handle them and they’re caused exclusively as the result of a program bug that never should have occurred.

If you have a followup question, shoot it! I'd be happy to help.

Добрый день!

Книга пока ещё не издана в бумажном виде. Если вы хотите быть в курсе когда это произойдёт, то можете подписаться на нашу рассылку.

Если вам кровь из носу необходимо иметь хоть какую-то бумажную книгу о паттернах, то рекомендую купить либо классическую книгу от банды четырёх «Design Patterns: Elements of Reusable Object-Oriented Software» (издана на русском как «Приёмы объектно-ориентированного проектирования. Паттерны проектирования»), либо более казуальную «Head First Design Patterns: A Brain-Friendly Guide» (рус. «Head First. Паттерны проектирования»). Обе книги имеют свои преимущества и недостатки, так что выбирайте ту, которая вам ближе.

Спасибо, я ещё раз глянул и увидел, что код как раз-то исправлен, а диаграмма — нет. Исправление заключалось в том, чтобы Dialog.renderWindow переименовать в Dialog.render.

Hi!

Some refactorings listed in our catalog are indeed possible to perform with automatic tools like PHPStorm and ReSharper. I think the JetBrains team have done outstanding work in that direction and I doubt any other non-implemented refactorings are even possible without human intervention.

Sorry, I forgot to update the status of this ticket. Swift examples have been released 2 months ago.