¿Por qué elegir Struct Over Class?

Jugando con Swift, proveniente de un fondo de Java, ¿por qué querrías elegir un Struct en lugar de un Class? Parece que son lo mismo, con un Struct que ofrece menos funcionalidad. ¿Por qué elegirlo entonces?

Según la muy popular WWDC 2015, la progtwigción orientada al protocolo en Swift ( video , transcripción ), Swift proporciona una serie de características que hacen que las estructuras sean mejores que las clases en muchas circunstancias.

Las estructuras son preferibles si son relativamente pequeñas y copiables porque la copia es mucho más segura que tener múltiples referencias a la misma instancia que ocurre con las clases. Esto es especialmente importante cuando se pasa una variable a muchas clases y / o en un entorno multiproceso. Si siempre puede enviar una copia de su variable a otros lugares, nunca tendrá que preocuparse de que ese otro lugar cambie el valor de su variable debajo de usted.

Con Structs, hay mucho menos necesidad de preocuparse por memory leaks o múltiples hilos de carrera para acceder / modificar una sola instancia de una variable. (Para los que tienen una mayor mentalidad técnica, la excepción a esto es cuando se captura una estructura dentro de un cierre porque en realidad está capturando una referencia a la instancia a menos que se marque explícitamente para ser copiada).

Las clases también pueden hincharse porque una clase solo puede heredar de una sola superclase. Eso nos anima a crear enormes superclases que abarcan muchas habilidades diferentes que solo están relacionadas de manera vaga. El uso de protocolos, especialmente con extensiones de protocolo donde puede proporcionar implementaciones a protocolos, le permite eliminar la necesidad de clases para lograr este tipo de comportamiento.

La charla presenta estos escenarios donde las clases son preferidas:

  • Copiar o comparar instancias no tiene sentido (p. Ej., Ventana)
  • La duración de la instancia está ligada a efectos externos (p. Ej., TemporaryFile)
  • Las instancias son simplemente “sumideros”: conductos de solo escritura para un estado externo (por ejemplo, CGContext)

Implica que las estructuras deberían ser las predeterminadas y las clases deberían ser un repliegue.

Por otro lado, la documentación de The Swift Programming Language es algo contradictoria:

Las instancias de estructura siempre pasan por valor, y las instancias de clase siempre se pasan por referencia. Esto significa que son adecuados para diferentes tipos de tareas. Al considerar las construcciones de datos y la funcionalidad que necesita para un proyecto, decida si cada construcción de datos debe definirse como una clase o como una estructura.

Como regla general, considere crear una estructura cuando se aplique una o más de estas condiciones:

  • El propósito principal de la estructura es encapsular unos pocos valores de datos relativamente simples.
  • Es razonable esperar que los valores encapsulados se copien en lugar de referenciar cuando asigna o pasa una instancia de esa estructura.
  • Todas las propiedades almacenadas por la estructura son en sí mismas tipos de valores, que también se espera que se copien en lugar de referenciarse.
  • La estructura no necesita heredar propiedades o comportamiento de otro tipo existente.

Ejemplos de buenos candidatos para estructuras incluyen:

  • El tamaño de una forma geométrica, quizás encapsulando una propiedad de ancho y una propiedad de alto, ambas de tipo Doble.
  • Una forma de referirse a los rangos dentro de una serie, tal vez encapsulando una propiedad de inicio y una propiedad de longitud, ambas de tipo Int.
  • Un punto en un sistema de coordenadas 3D, tal vez encapsulando propiedades x, y y z, cada una de tipo Doble.

En todos los demás casos, defina una clase y cree instancias de esa clase para administrar y pasar por referencia. En la práctica, esto significa que la mayoría de las construcciones de datos personalizadas deben ser clases, no estructuras.

Aquí se afirma que debemos usar las clases por defecto y usar estructuras solo en circunstancias específicas. En última instancia, debe comprender la implicación en el mundo real de los tipos de valores frente a los tipos de referencia y luego puede tomar una decisión informada sobre cuándo usar estructuras o clases. Además, tenga en cuenta que estos conceptos siempre están evolucionando y que la documentación de The Swift Programming Language se escribió antes de que se diera la charla de Progtwigción Orientada a Protocolo.

Como las instancias struct se asignan en la stack y las instancias de la clase se asignan en el montón, las estructuras a veces pueden ser drásticamente más rápidas.

Sin embargo, siempre debe medirlo usted mismo y decidir en función de su caso de uso único.

Considere el siguiente ejemplo, que muestra 2 estrategias de Int tipo de datos Int utilizando struct y class . Estoy usando 10 valores repetidos para reflejar mejor el mundo real, donde tienes múltiples campos.

 class Int10Class { let value1, value2, value3, value4, value5, value6, value7, value8, value9, value10: Int init(_ val: Int) { self.value1 = val self.value2 = val self.value3 = val self.value4 = val self.value5 = val self.value6 = val self.value7 = val self.value8 = val self.value9 = val self.value10 = val } } struct Int10Struct { let value1, value2, value3, value4, value5, value6, value7, value8, value9, value10: Int init(_ val: Int) { self.value1 = val self.value2 = val self.value3 = val self.value4 = val self.value5 = val self.value6 = val self.value7 = val self.value8 = val self.value9 = val self.value10 = val } } func + (x: Int10Class, y: Int10Class) -> Int10Class { return IntClass(x.value + y.value) } func + (x: Int10Struct, y: Int10Struct) -> Int10Struct { return IntStruct(x.value + y.value) } 

El rendimiento se mide usando

 // Measure Int10Class measure("class (10 fields)") { var x = Int10Class(0) for _ in 1...10000000 { x = x + Int10Class(1) } } // Measure Int10Struct measure("struct (10 fields)") { var y = Int10Struct(0) for _ in 1...10000000 { y = y + Int10Struct(1) } } func measure(name: String, @noescape block: () -> ()) { let t0 = CACurrentMediaTime() block() let dt = CACurrentMediaTime() - t0 print("\(name) -> \(dt)") } 

El código se puede encontrar en https://github.com/knguyen2708/StructVsClassPerformance

ACTUALIZACIÓN (27 de marzo de 2018) :

A partir de Swift 4.0, Xcode 9.2, ejecutando Release build en iPhone 6S, iOS 11.2.6, la configuración Swift Compiler es -O -whole-module-optimization :

  • class versión de class tomó 2.06 segundos
  • struct versión struct tardó 4.17e-08 segundos (50,000,000 veces más rápido)

(Ya no promedie varias ejecuciones, ya que las variaciones son muy pequeñas, menos del 5%)

Nota : la diferencia es mucho menos dramática sin la optimización del módulo completo. Me alegra que alguien pueda señalar lo que realmente hace la bandera.


ACTUALIZACIÓN (7 de mayo de 2016) :

A partir de Swift 2.2.1, Xcode 7.3, ejecutando Release build en iPhone 6S, iOS 9.3.1, promedió más de 5 ejecuciones, la configuración Swift Compiler es -O -whole-module-optimization :

  • class versión de class tomó 2.159942142s
  • struct versión struct tomó 5.83E-08s (37,000,000 veces más rápido)

Nota : como alguien mencionó que en los escenarios del mundo real, probablemente haya más de un campo en una estructura, he agregado pruebas para las estructuras / clases con 10 campos en lugar de 1. Sorprendentemente, los resultados no varían mucho.


RESULTADOS ORIGINALES (1 de junio de 2014):

(Funcionó en struct / class con 1 campo, no 10)

A partir de Swift 1.2, Xcode 6.3.2, ejecutando Release build en iPhone 5S, iOS 8.3, promedió más de 5 carreras

  • class versión de class tomó 9.788332333s
  • struct versión struct tomó 0.010532942s (900 veces más rápido)

ANTIGUOS RESULTADOS (desde tiempo desconocido)

(Funcionó en struct / class con 1 campo, no 10)

Con la versión de lanzamiento en mi MacBook Pro:

  • La versión de class tomó 1.10082 sec
  • La versión struct tomó 0.02324 segundos (50 veces más rápido)

Similitudes entre estructuras y clases.

Creé gist para esto con ejemplos simples. https://github.com/objc-swift/swift-classes-vs-structures

Y diferencias

1. Herencia

las estructuras no pueden heredar de forma rápida. Si tu quieres

 class Vehicle{ } class Car : Vehicle{ } 

Ir a una clase

2. Pase por

Las estructuras Swift pasan por valor y las instancias de clase pasan por referencia.

Diferencias contextuales

Struct constante y variables

Ejemplo (utilizado en WWDC 2014)

 struct Point{ var x = 0.0; var y = 0.0; } 

Define una estructura llamada Point.

 var point = Point(x:0.0,y:2.0) 

Ahora si trato de cambiar la x. Es una expresión válida.

 point.x = 5 

Pero si definí un punto como constante.

 let point = Point(x:0.0,y:2.0) point.x = 5 //This will give compile time error. 

En este caso, el punto entero es constante inmutable.

Si usé un punto de clase en cambio, esta es una expresión válida. Porque en una clase la constante inmutable es la referencia a la clase en sí misma, no a sus variables de instancia (a menos que esas variables se definan como constantes)

Aquí hay algunas otras razones para considerar:

  1. las estructuras obtienen un inicializador automático que no tiene que mantener en absoluto el código.

     struct MorphProperty { var type : MorphPropertyValueType var key : String var value : AnyObject enum MorphPropertyValueType { case String, Int, Double } } var m = MorphProperty(type: .Int, key: "what", value: "blah") 

Para obtener esto en una clase, debería agregar el inicializador y mantener el inicializador …

  1. Los tipos básicos de colección como Array son estructuras. Cuanto más los use en su propio código, más se acostumbrará a pasar por valor en lugar de referencia. Por ejemplo:

     func removeLast(var array:[String]) { array.removeLast() println(array) // [one, two] } var someArray = ["one", "two", "three"] removeLast(someArray) println(someArray) // [one, two, three] 
  2. Aparentemente, la inmutabilidad frente a la mutabilidad es un tema enorme, pero mucha gente inteligente cree que la inmutabilidad (en este caso, las estructuras) es preferible. Mutable vs objetos inmutables

Algunas ventajas:

  • automáticamente threadsafe debido a que no se puede compartir
  • usa menos memoria debido a que no hay isa y refcount (y, de hecho, se asigna la stack en general)
  • los métodos siempre se envían de forma estática, por lo que pueden estar en línea (aunque @final puede hacer esto para las clases)
  • más fácil de razonar (no es necesario “copiar a la defensiva” como es típico con NSArray, NSString, etc …) por la misma razón que la seguridad de los hilos

Suponiendo que sepamos que Struct es un tipo de valor y Class es un tipo de referencia .

Si no sabe qué tipo de valor y qué tipo de referencia son, entonces vea ¿Cuál es la diferencia entre pasar por referencia y pasar por valor?

Basado en la publicación de mikeash :

… Veamos algunos ejemplos extremos y obvios primero. Los enteros son obviamente copiables. Deben ser tipos de valores. Los sockets de red no se pueden copiar con sensatez. Deben ser tipos de referencia. Los puntos, como en los pares x, y, se pueden copiar. Deben ser tipos de valores. Un controlador que representa un disco no puede copiarse con sensatez. Eso debería ser un tipo de referencia.

Algunos tipos pueden copiarse, pero puede no ser algo que quiera que suceda todo el tiempo. Esto sugiere que deberían ser tipos de referencia. Por ejemplo, un botón en la pantalla puede ser copiado conceptualmente. La copia no será exactamente idéntica a la original. Un clic en la copia no activará el original. La copia no ocupará la misma ubicación en la pantalla. Si pasa el botón o lo coloca en una nueva variable, probablemente querrá referirse al botón original y solo querrá hacer una copia cuando se solicite explícitamente. Eso significa que su tipo de botón debe ser un tipo de referencia.

Los controladores de vista y ventana son un ejemplo similar. Podrían ser copiables, posiblemente, pero casi nunca es lo que te gustaría hacer. Deben ser tipos de referencia.

¿Qué hay de los tipos de modelo? Puede tener un tipo de Usuario que represente a un usuario en su sistema, o un tipo de Crimen que represente una acción tomada por un Usuario. Estos son bastante copiables, por lo que probablemente deberían ser tipos de valor. Sin embargo, probablemente desee que las actualizaciones de un Delito del usuario se realicen en un lugar de su progtwig para que sean visibles para otras partes del progtwig. Esto sugiere que sus usuarios deberían ser administrados por algún tipo de controlador de usuario que sería un tipo de referencia .

Las colecciones son un caso interesante. Estos incluyen cosas como matrices y diccionarios, así como cadenas. ¿Se pueden copiar? Obviamente. ¿Está copiando algo que quiere que suceda fácilmente y con frecuencia? Eso es menos claro.

La mayoría de los idiomas dicen “no” a esto y hacen sus tipos de referencia de colecciones. Esto es cierto en Objective-C, Java, Python, JavaScript y casi cualquier otro lenguaje que se me ocurra. (Una excepción importante es C ++ con tipos de colección STL, pero C ++ es el delirante del mundo de la lengua que hace todo de forma extraña).

Swift dijo “sí”, lo que significa que tipos como Array, Dictionary y String son estructuras en lugar de clases. Se copian en la tarea y al pasarlos como parámetros. Esta es una opción totalmente sensata siempre que la copia sea barata, lo que Swift intenta muy difícilmente. …

Además, no use la clase cuando tenga que anular todas y cada una de las instancias de una función, es decir, que no tengan ninguna funcionalidad compartida .

Entonces, en lugar de tener varias subclases de una clase. Usa varias estructuras que se ajusten a un protocolo.

La estructura es mucho más rápida que la clase. Además, si necesita herencia, debe usar Class. El punto más importante es que Clase es tipo de referencia, mientras que Estructura es tipo de valor. por ejemplo,

 class Flight { var id:Int? var description:String? var destination:String? var airlines:String? init(){ id = 100 description = "first ever flight of Virgin Airlines" destination = "london" airlines = "Virgin Airlines" } } struct Flight2 { var id:Int var description:String var destination:String var airlines:String } 

ahora permite crear una instancia de ambos.

 var flightA = Flight() var flightB = Flight2.init(id: 100, description:"first ever flight of Virgin Airlines", destination:"london" , airlines:"Virgin Airlines" ) 

ahora pasemos estas instancias a dos funciones que modifican la identificación, descripción, destino, etc.

 func modifyFlight(flight:Flight) -> Void { flight.id = 200 flight.description = "second flight of Virgin Airlines" flight.destination = "new york" flight.airlines = "Virgin Airlines" } 

además,

 func modifyFlight2(flight2: Flight2) -> Void { var passedFlight = flight2 passedFlight.id = 200 passedFlight.description = "second flight from virgin airlines" } 

asi que,

 modifyFlight(flight: flightA) modifyFlight2(flight2: flightB) 

ahora si imprimimos la identificación y la descripción de flightA, obtenemos

 id = 200 description = "second flight of Virgin Airlines" 

Aquí, podemos ver que la identificación y la descripción de FlightA se modifican porque el parámetro pasado al método de modificación realmente apunta a la dirección de memoria del objeto flightA (tipo de referencia).

ahora si imprimimos la identificación y la descripción de la instancia de FLightB obtenemos,

 id = 100 description = "first ever flight of Virgin Airlines" 

Aquí podemos ver que la instancia FlightB no se cambia porque en el método modifyFlight2, la instancia real de Flight2 es pasa en lugar de referencia (tipo de valor).

Con las clases obtienes herencia y se pasan por referencia, las estructuras no tienen herencia y se pasan por valor.

Hay grandes sesiones WWDC en Swift, esta pregunta específica se responde con detalle en uno de ellos. Asegúrate de verlos, ya que te permitirá acelerar mucho más rápido que la guía de idiomas o el iBook.

Respondiendo a la pregunta desde la perspectiva de los tipos de valores frente a los tipos de referencia, desde esta publicación del blog de Apple parece muy simple:

Use un tipo de valor [por ejemplo, struct, enum] cuando:

  • Comparar los datos de instancia con == tiene sentido
  • Desea que las copias tengan un estado independiente
  • Los datos se usarán en código a través de múltiples hilos

Use un tipo de referencia [p. Ej. Clase] cuando:

  • Comparar la identidad de instancia con === tiene sentido
  • Desea crear un estado compartido y mutable

Como se menciona en ese artículo, una clase sin propiedades escribibles se comportará de manera idéntica con una estructura, con (añadiré) una advertencia: las estructuras son mejores para los modelos seguros para subprocesos , un requisito cada vez más inminente en la architecture de aplicaciones moderna.

No diría que las estructuras ofrecen menos funcionalidad.

Claro, el yo es inmutable excepto en una función de mutación, pero eso es todo.

La herencia funciona bien siempre y cuando te apegues a la buena idea de que cada clase debe ser abstracta o definitiva.

Implementar clases abstractas como protocolos y clases finales como estructuras.

Lo bueno de las estructuras es que puedes hacer que tus campos se puedan modificar sin crear un estado mutable compartido, porque copy on write se encarga de eso 🙂

Es por eso que las propiedades / campos en el siguiente ejemplo son todos mutables, lo que no haría en Java o C # o clases rápidas.

Ejemplo de estructura de herencia con un poco de uso sucio y directo en la parte inferior de la función denominada “ejemplo”:

 protocol EventVisitor { func visit(event: TimeEvent) func visit(event: StatusEvent) } protocol Event { var ts: Int64 { get set } func accept(visitor: EventVisitor) } struct TimeEvent : Event { var ts: Int64 var time: Int64 func accept(visitor: EventVisitor) { visitor.visit(self) } } protocol StatusEventVisitor { func visit(event: StatusLostStatusEvent) func visit(event: StatusChangedStatusEvent) } protocol StatusEvent : Event { var deviceId: Int64 { get set } func accept(visitor: StatusEventVisitor) } struct StatusLostStatusEvent : StatusEvent { var ts: Int64 var deviceId: Int64 var reason: String func accept(visitor: EventVisitor) { visitor.visit(self) } func accept(visitor: StatusEventVisitor) { visitor.visit(self) } } struct StatusChangedStatusEvent : StatusEvent { var ts: Int64 var deviceId: Int64 var newStatus: UInt32 var oldStatus: UInt32 func accept(visitor: EventVisitor) { visitor.visit(self) } func accept(visitor: StatusEventVisitor) { visitor.visit(self) } } func readEvent(fd: Int) -> Event { return TimeEvent(ts: 123, time: 56789) } func example() { class Visitor : EventVisitor { var status: UInt32 = 3; func visit(event: TimeEvent) { print("A time event: \(event)") } func visit(event: StatusEvent) { print("A status event: \(event)") if let change = event as? StatusChangedStatusEvent { status = change.newStatus } } } let visitor = Visitor() readEvent(1).accept(visitor) print("status: \(visitor.status)") } 

En Swift, se ha introducido un nuevo patrón de progtwigción conocido como Progtwigción Orientada a Protocolo.

Patrón de creación:

Rápidamente, Struct es un tipo de valor que se clona automáticamente. Por lo tanto, obtenemos el comportamiento requerido para implementar el patrón prototipo de forma gratuita.

Mientras que las clases son el tipo de referencia, que no se clona automáticamente durante la asignación. Para implementar el patrón prototipo, las clases deben adoptar el protocolo NSCopying .


La copia superficial duplica solo la referencia, que apunta a esos objetos, mientras que la copia profunda duplica la referencia del objeto.


Implementar una copia profunda para cada tipo de referencia se ha convertido en una tarea tediosa. Si las clases incluyen más tipo de referencia, tenemos que implementar un patrón prototipo para cada una de las propiedades de referencia. Y luego tenemos que copiar el gráfico completo del objeto implementando el protocolo NSCopying .

 class Contact{ var firstName:String var lastName:String var workAddress:Address // Reference type } class Address{ var street:String ... } 

Mediante el uso de estructuras y enumeraciones , simplificamos nuestro código ya que no tenemos que implementar la lógica de copia.

Muchas API de Cocoa requieren subclases de NSObject, lo que te obliga a utilizar la clase. Pero aparte de eso, puede usar los siguientes casos del blog Swift de Apple para decidir si se usa un tipo de valor struct / enum o un tipo de referencia de clase.

https://developer.apple.com/swift/blog/?id=10

Un punto que no llama la atención en estas respuestas es que una variable que contiene una clase frente a una estructura puede ser un let mientras permite cambios en las propiedades del objeto, mientras que no se puede hacer con una estructura.

Esto es útil si no desea que la variable apunte a otro objeto, pero aún necesita modificar el objeto, es decir, en el caso de tener muchas variables de instancia que desea actualizar una tras otra. Si es una estructura, debe permitir que la variable se restablezca a otro completamente utilizando var para hacerlo, ya que un tipo de valor constante en Swift permite una mutación cero, mientras que los tipos de referencia (clases) no se comportan de esta manera. .

Como struct son tipos de valores y puede crear la memoria muy fácilmente, que se almacena en stack. Se puede acceder fácilmente a Struct y después del scope del trabajo se puede desasignar fácilmente de la memoria de stack a través de pop desde la parte superior de la stack. Por otro lado, la clase es un tipo de referencia que almacena en montón y los cambios realizados en un objeto de clase afectarán a otro objeto, ya que están estrechamente relacionados y son de tipo referencia. Todos los miembros de una estructura son públicos, mientras que todos los miembros de una clase son privados .

Las desventajas de struct es que no se puede heredar.

  • La estructura y la clase son tipos de datos definidos por el usuario

  • Por defecto, la estructura es pública, mientras que la clase es privada

  • La clase implementa el principio de encapsulación

  • Los objetos de una clase se crean en la memoria del montón

  • La clase se usa para volver a usarla mientras que la estructura se usa para agrupar los datos en la misma estructura

  • Los miembros de datos de estructura no pueden inicializarse directamente, pero pueden ser asignados por el exterior de la estructura

  • Los miembros de datos de clase se pueden inicializar directamente por el parámetro menos constructor y asignados por el constructor parametrizado