Тестирование поставщика Членства без ASP.NET

В соответствии с очень популярным докладом WWDC 2015 по протоколу ориентированного программирования в Swift (видео , , стенограмма ), Swift предоставляет ряд функций, которые делают структуры лучше, чем классы, во многих обстоятельствах.

Структуры предпочтительнее, если они относительно малы и копируемы, потому что копирование намного безопаснее, чем множественные ссылки на один и тот же экземпляр, как это происходит с классами. Это особенно важно при передаче переменной во многие классы и / или в многопоточной среде. Если вы всегда можете отправить копию своей переменной в другие места, вам никогда не придется беспокоиться о том, что это другое место изменит значение вашей переменной под вами.

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

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

В докладе изложены следующие сценарии, в которых предпочтительны классы:

• Копирование или сравнение экземпляров не имеет смысла (например, Window)
• Время жизни экземпляра связано к внешним эффектам (например, TemporaryFile)
• Экземпляры - это просто «приемники» - каналы только для записи во внешнее состояние (например, CGContext)

Это означает, что структуры должны по умолчанию, и классы должны быть запасным вариантом.

С другой стороны, документация Swift Programming Language несколько противоречива:

Экземпляры структуры всегда передаются по значению, а экземпляры класса всегда передаются по ссылке. Это означает, что они подходят для различных задач. Рассматривая конструкции данных и функциональные возможности, которые необходимы для проекта, решите, следует ли определять каждую конструкцию данных как класс или структуру.

В качестве общего руководства рассмотрите возможность создания структуры, когда применяется одно или несколько из следующих условий:

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

Примеры хороших кандидатов для структур включают:

• Размер геометрической фигуры, возможно, инкапсулируя свойство ширины и свойство высоты, оба типа Double.
• Способ ссылки на диапазоны внутри ряда, возможно, инкапсулируя свойство start и свойство length, оба типа Int.
• Точка в трехмерной системе координат, возможно, инкапсулирующая свойства x, y и z, каждый из которых имеет тип Double.

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

Здесь утверждается, что мы должны по умолчанию использовать классы и использовать структуры только в определенных обстоятельствах. В конечном счете, вам необходимо понять реальное значение типов значений по сравнению с ссылочными типами, и тогда вы сможете принять обоснованное решение о том, когда использовать структуры или классы. Кроме того, имейте в виду, что эти концепции постоянно развиваются, и документация по Swift Programming Language была написана до того, как была сделана речь о протоколно-ориентированном программировании.