Gang of Four - Design Patterns - это образцы шаблонов, устаревшие?

Ответ 1

Они немного устарели, да. Но часть этих книг состоит в том, что эти шаблоны полезны на нескольких разных языках и имеют несколько разных стилей. Поэтому, хотя код немного устарел в зубе, идей, стоящих за ним, нет, и эти идеи важны в этих книгах.

Я хотел бы увидеть некоторые реализации шаблонов, которые использовали методы метапрограммирования. Я сильно подозреваю, что некоторые шаблоны, такие как Bridge, Adapter и, возможно, Facade, гораздо менее утомительны для реализации с использованием метапрограмм. Из другого ответа и чтения описания это выглядит как Современный дизайн С++: общие шаблоны программирования и дизайна, применяемые, может быть хорошей книгой для такого рода вещей. Я не могу лично ручаться за это, хотя.

Помимо возможного использования общих методов программирования и шаблонов, основные отличия в том, что в настоящее время в С++ редко присутствуют голые указатели. Существуют эффективные типы интеллектуальных указателей, которые обычно используются вместо них, потому что они обрабатывают много проблем управления ресурсами для вас. Честно говоря, если вы точно не знаете, что делаете, я бы вообще не рекомендовал делать универсальный дизайн на основе программирования.

Вот несколько примеров того, какие типы интеллектуальных указателей используются в разных контекстах. В этих примерах предполагается, что у вас есть С++, который включает расширения TR1 (технический отчет 1):

Если у вас есть указатель на то, что полностью принадлежит объекту, указывающему на него, используйте ::std::auto_ptr (или ::std::unique_ptr в С++ 1x). Имейте в виду, что ::std::auto_ptr нельзя хранить в контейнерах STL, но ::std::unique_ptr не имеет этой проблемы. Примерами могут быть шаблон Component (пока не были разделены две подкомпоненты), шаблон Facade и шаблон адаптера. Кроме того, шаблон Factory должен, вероятно, создавать ::std::auto_ptr (или ::std::unique_ptr в С++ 1x), если не существует действительно веской причины для создания ::std::shared_ptr s.

Когда у вас есть указатель на то, что имеет совместное владение, используется ::std::tr1::shared_ptr. Например, шаблон Flyweight. Кроме того, в некоторых случаях шаблон компонента также может иметь это свойство. Он также может быть полезен в шаблоне Bridge.

Если у вас есть указатель на то, что для чего-то, чего вы не логически владеете, тогда ::std::tr1::weak_ptr - это путь. Имейте в виду, что если вы используете ::std::tr1::weak_ptr, вы также должны использовать ::std::tr1::shared_ptr для всех объектов, которые логически владеют (или обмениваются собственностью) объекта, указанного в элементе. Примером этого является шаблон Observer.

Ответ 2

Авторы использовали код в качестве примеров, а не то, что они написали производственный код. Производственный код более надежный и проверяет наличие ошибок и исключений. Такие книги обычно не показывают их, они также не содержат блок try-catch или другую бизнес-логику.

Книга предназначена для идей, концепций, как разработать свою программу для решения часто встречающихся проблем программного обеспечения, а не для того, какой синтаксис или код использовать. Кроме того, везде, где авторы использовали исходные указатели, вы можете заменить их умными указателями и симпатичными (если возможно), чтобы сделать его более надежным.

Однако динамический полиморфизм может быть достигнут только с помощью указателей или ссылок, поэтому они все еще действительны и используются даже в производственном коде.

Кроме того, верно и то, что в последнее десятилетие способ написания кода на С++ сильно изменился. Таким образом, вы можете включить эти новые методы со старой идеей/шаблонами, представленными в книге GOF. Например, Andrei Alexandrescu использовал шаблоны для реализации многих шаблонов (старых шаблонов) в своей книге:

Современный дизайн С++: общие шаблоны программирования и дизайна