2.8 Classes and Structures
Just as in many other languages that support the Object Oriented paradigm, Swift provides you with the ability to create your own types that contain properties and methods to encapsulate your own custom functionality. In this lesson, we will introduce the high-level concept of classes and structures, as well as some basic guidelines on when to use either one.
1.Introduction4 lessons, 26:24
2.Language Constructs12 lessons, 1:51:34
3.Swift and Object Oriented Programming5 lessons, 27:52
4.Built-In Types5 lessons, 42:18
5.Conclusion1 lesson, 01:19
2.8 Classes and Structures
In the next couple of lessons, we're gonna introduce the concept of being able to create your own types within your SWF application and then reuse those types wherever you deem it necessary. Now there's a couple different ways to create your own types within SWF and that is via the class or the structure. Now, while they are foundationally, very simple, similar by being able to encapsulate some data or some properties or functionality, you really can use them interchangeably whenever you want. So you don't have to worry about when should I use a class, when should I use a structive, you're just trying to do a very basic concepts. But the minute you start to get into a little bit more advanced topics, like object oriented programming, then you're gonna have to lean towards a class. And so let's get into looking a little bit about what the class and a structive look like and then we'll talk about some use cases where you're gonna wanna pick one over the other. So, as I said, class and structure are very similar. So we can start by creating a class by using the class keyword and then we can say that this is going to be called the CalculatorClass. Then within here, you're gonna see here we can, we can specify properties and methods. And we're gonna talk a little bit more about about properties and methods in the upcoming lessons. And then if I wanted to create a structure, we use this struct keyword. And in this case, I'm gonna say that this is the CalculatorStruct. Once again, I can define properties and methods in here. So, as you can see from a language perspective, these are both going to do basically the same thing. Now, if you're familiar with objective scene, you've done some iOS programming in the past, you're gonna see the main, one of the main differences of these has to do with reference counting. So when you start to create new instances and you want the platform to be able to help you in the way of garbage collection and being able to get rid of unused memory and reclaim that memory, then the class is what's going to mirror that sort of functionality, where a class is a reference type. Which means that when you're using reference counting, every time you instantiate a new instance of a class, the reference count is going to increase by one. Now the struct on the other hand does not do this. The structure is a value type which means, it's basically like creating integers or Booleans or just some sort of very simple data representation that does not increase reference counts and does not get garbage collected. So from a platform perspective, that's one of the differences. When it comes to functionality differences, a class is what you use if you're interested in following some of the paradigms behind object-oriented programming say, inheritance, where I create some sort of base functionality. So let's say, I was creating a calculator. Now there's multiple different kinds of calculators. There's binary calculators, there's scientific calculators and all sorts of variations of a calculator. But one thing that remains true throughout most calculators at least is that they can do basic operations, such as addition, subtraction, multiplication and division. So, in that case, what I could do if I was designing this in an object oriented way. I could create a base calculator class that would contain that functionality to be able to do all those basic operations and then I could create a scientific CalculatorClass that would do all the more complex calculations, but then I could make the scientific calculator inherit from that base calculator. So now the scientific calculator benefits from the implementation of addition, subtraction, multiplication and division from that base class, from that base definition of a calculator without having to duplicate it in of itself. So, it reduces the need for co-duplication, which is really a bad thing to have in your code anyway. So anyway, anytime, you can actually get rid of it, you're gonna be much better off. So when do you want to choose between these two? Well, there's several different instances where you're gonna need to choose between them. But as kind of a general rule, I guess. When you're going to choose a, an implementation where you're gonna want to use some of that inheritance functionality or any sort of object-oriented concepts, then you're going to have to use a class. That is just kind of, the way that it goes. And if you're going to create some more complicated structures and ca or complicated types, that's going to contain a lot of properties and methods. And I typically follow the paradigm of using a class, it's just the way that I'm wired internally and that's where I'm going to ultimately default to quite often. Anytime where you want to, as I mentioned before, take advantage of the reference counting, so that you can have some help in making sure that your footprint in your application is going to be as small as possible by taking advantage of the reference counting and ultimately the garbage collection, then you're gonna wanna use a class. So, if it's something that you find yourself probably going to be creating a lot of instances of and you're probably going to wanna take advantage of that as well, because you can then reclaim that unused memory once that particular instance of that class is no longer needed. So when it comes to structures, you're probably going to use those in instances where you're just creating simple data types, maybe a data type that's going to represent a point on a graph or maybe on a grid system. Or if you're going to create type that's going to represent a range of values or maybe some shapes and widths and heights and simple things like that, then instruct is probably not a bad thing to choose. Now, if I'm just being honest here. Very rarely, do I ever actually use structures. In my day to day programming regardless of the language that I'm using, if I'm doing any sort of creation of my own types, I'm 99.5% of the time going to use classes. Like I said that's just the way that I operate, but it's ultimately going to be up to you and whatever is the best fit for your particular functionality that your looking for. And ultimately, what you're looking to get out of this custom type. So now, in the next couple of lessons, we're going to focus more on the guts of the class, namely the properties and the methods and the things that we can do with them within our class.