Classes vs. Structures in Swift 4, Xcode 9, and iOS 11 - raywenderlich.com

preview_player
Показать описание
Learn about the differences between classes and structures in Swift, and when you should use which.

Watch the full course here:

----

We are also focused on developing a strong community. Our goal is to help each other reach our dreams through friendship and cooperation. As you can see below, a bunch of us have joined forces to make this happen: authors, editors, subject matter experts, app reviewers, and most importantly our amazing readers!
---

Classes and structures are general-purpose, flexible constructs that become the building blocks of your program’s code. You define properties and methods to add functionality to your classes and structures by using exactly the same syntax as for constants, variables, and functions.

Unlike other programming languages, Swift does not require you to create separate interface and implementation files for custom classes and structures. In Swift, you define a class or a structure in a single file, and the external interface to that class or structure is automatically made available for other code to use.

Note: An instance of a class is traditionally known as an object. However, Swift classes and structures are much closer in functionality than in other languages, and much of this chapter describes functionality that can apply to instances of either a class or a structure type. Because of this, the more general term instance is used.

Classes and structures in Swift have many things in common. Both can:

● Define properties to store values

● Define methods to provide functionality

● Define subscripts to provide access to their values using subscript syntax

● Define initializers to set up their initial state

● Be extended to expand their functionality beyond a default implementation

● Conform to protocols to provide standard functionality of a certain kind

Classes have additional capabilities that structures do not:

● Inheritance enables one class to inherit the characteristics of another.

● Type casting enables you to check and interpret the type of a class instance at runtime.

● Deinitializers enable an instance of a class to free up any resources it has assigned.

● Reference counting allows more than one reference to a class instance.

Classes and structures have a similar definition syntax. You introduce classes with the class keyword and structures with the struct keyword.

Structures and Enumerations Are Value Types

A value type is a type whose value is copied when it is assigned to a variable or constant, or when it is passed to a function.

You’ve actually been using value types extensively throughout the previous chapters. In fact, all of the basic types in Swift—integers, floating-point numbers, Booleans, strings, arrays and dictionaries—are value types, and are implemented as structures behind the scenes.

All structures and enumerations are value types in Swift. This means that any structure and enumeration instances you create—and any value types they have as properties—are always copied when they are passed around in your code.

Classes Are Reference Types

Unlike value types, reference types are not copied when they are assigned to a variable or constant, or when they are passed to a function. Rather than a copy, a reference to the same existing instance is used instead.

Choosing Between Classes and Structures

You can use both classes and structures to define custom data types to use as the building blocks of your program’s code.

However, structure instances are always passed by value, and class instances are always passed by reference. This means that they are suited to different kinds of tasks. As you consider the data constructs and functionality that you need for a project, decide whether each data construct should be defined as a class or as a structure.

As a general guideline, consider creating a structure when one or more of these conditions apply:

● The structure’s primary purpose is to encapsulate a few relatively simple data values.

● It is reasonable to expect that the encapsulated values will be copied rather than referenced when you assign or pass around an instance of that structure.

● Any properties stored by the structure are themselves value types, which would also be expected to be copied rather than referenced.

● The structure does not need to inherit properties or behavior from another existing type.
Рекомендации по теме
Комментарии
Автор

Awesome video! I especially liked the real world examples at the end on when to use classes vs structs. Most helpful.

JR-yiwb
Автор

Explained so clearly! Loved it! Thank you!

kevinpeng
Автор

marvelous very very nicely explained with simple example awesome!!!

solomonrajkumar
Автор

really nice and clean and neat explanations.Thanks Ray

sandeep
Автор

Hello, nested or not nested structures? which practice is better?

sergeirodin
Автор

Good and clear explanation, thank you, Ray Wenderlich :-)

SenthilKumaranu
Автор

I mean... Why do we need universities anymore?

cappuccinopapi
Автор

great explaining, class can inherit but structure no inheritance

saadbadr
Автор

So you can do the same trick in Swift as in C: assign entire contents of structs from one to another simply by assigning them (using =)

tenminutetokyo
Автор

Sir please upload the core data and framework

madhun
Автор

Thank you so much for this clarifying video!
Would it be possible to know when structs need their own initialisers? This got me very confused.
I saw structs having initialisers without all their properties in them or with names very different from their original properties ones.
Thanks!

TheBardsCorner
Автор

Can you please explain why you use "self" in self.firstName. What does it do? Why is it needed? Thanks.

SwitChblDe
Автор

At 2:38 he says "If a STACK belongs to a CLASS". He meant a STRUCT belongs to a CLASS right? Then the struct would be placed at the heap. That would be the exception

oliverm.batista
Автор

Dude, can you use $25 from my monthly fee and get a tan? You almost blend in with the wall. Lol

bobbyv
Автор

I keep hearing this over and over again. "Start with struct and just change to class later". Yes, except you likely break everything. For example....every computed property that points to a struct. The setter doesn't get called when it's a reference type but it does if it's a struct. Even worse going from class to struct. Anything declared with let now need to be changed to a var. All protocol methods now have to be marked mutating. Have fun with that. Structs are a lie. Class all the things.

ilovepickles
Автор

Can you slow down a bit? You are speaking too fast and non-native speakers can’t catch up, thanks

rahafalhelo
welcome to shbcf.ru