Enumerations and Optionals: Intro to Enums (Part 1)
So here we go! I'm now 'up to date'. I can't claim that I've gone over EVERYTHING that I had learned in the previous few years, but by going through the four Treehouse courses, I feel as though I have a thorough understanding of what I should know. Just to recap, I've been re-learning constants, variables, types, operations, collections, conditionals and control flow, functions, methods, classes and structures...that's actually really impressive! I got a little lost towards the end of classes - specifically the initialisation aspect, plus the fact that I was combining a lot of concepts together. I tried to go over this but it is genuinely a real challenge to make sense of; the key point is that I've tried and will continue to gain experience. Yesterday, I looked up the init aspect and tried out a few more examples, plus went over with my 'Swifty' app. It's coming!
Now, moving onwards, I'm doing a course about enumerations. From what I remember, these were a way of creating a set of values e.g. planets of the solar system, so they are not just strings but cases...and I think they operate similar to a 'switch' statement. So, here we go!
The Problem with Primitives
An enum is a construct that allows you to model a finite group of data/related types. Enums are flexible - they resemble objects. It is the fixed set of values. Pasan relates this to 'week' for a calendar app - days of the week. He creates an array to show a string for each day of the week. I'm not actually typing out the array and the function, as it's doomed! An enum is going to be far more efficient for this. Something that has just clicked is that an enum gives you set options - this would apply to other snippets of code I have carried out before. It avoids typos and errors and allows you to SELECT the option!
Modelling Finite Data
Enums use UpperCamelCase.
It is impossible to make an error - there is only a finite selection of values! This makes total sense! There's no default above, as I have included ALL of them. It is EXHAUSTIVE! So I could have done the weekday values as the default - that would have meant for neater code. Things like planets, seasons, months of the year etc. - these are fixed and have finite options. For my F1 game, there would be fixed options.
Getting Rid of Strings
Using custom enums - avoids errors from typing strings as there are finite options!
This was the challenge that actually proved fairly easy in the end. It sounded confusing but I applied what I had learned. The key thing was not returning anything from the function, which, up to now on this course I had been doing. I still needed to switch direction and present each case, but not return a value, instead alter a previous value.
It's better to do a little bit here and there than loads in one go, hence why I'm splitting the first section of this course into two parts. This means that there will probably be around 6 blogs for this particular course, which is fine! I may do the second part later, but there's no urgency to. I've found a good routine for doing this 'bit at a time', allowing the knowledge to sink in. With the whole enum thing becoming ever clearer, it's made me think about my F1 game. In that, I would have at a corner, several different possibilities: for there to be DPs paid, off track or no problem. Each of these could be cases of an Enum, so the string doesn't have to be typed in!
There will be many more examples within that game, and other ideas I'm sure. For now, I'm going to leave enums. The key takeaways are that they are for finite sets of data (days of week, months of year, outcomes from corner etc.), use the UpperCamelCase, but lowerCamelCase for the cases. The enum can be switched within a function or elsewhere, they reduce the chance of errors and give set options for coding. There are shortcuts with the syntax - not using 'case' every time, but writing a list; using just .then the case, rather than the Enum.case each time. Next time, there will be two more videos and two more challenges, including how they link to Methods...
Now, moving onwards, I'm doing a course about enumerations. From what I remember, these were a way of creating a set of values e.g. planets of the solar system, so they are not just strings but cases...and I think they operate similar to a 'switch' statement. So, here we go!
The Problem with Primitives
An enum is a construct that allows you to model a finite group of data/related types. Enums are flexible - they resemble objects. It is the fixed set of values. Pasan relates this to 'week' for a calendar app - days of the week. He creates an array to show a string for each day of the week. I'm not actually typing out the array and the function, as it's doomed! An enum is going to be far more efficient for this. Something that has just clicked is that an enum gives you set options - this would apply to other snippets of code I have carried out before. It avoids typos and errors and allows you to SELECT the option!
Modelling Finite Data
Enums use UpperCamelCase.
enum Day {
case sunday, monday, tuesday, wednesday, thursday, friday, saturday
}
func dayType(for day: Day) -> String {
switch day {
case .friday, .saturday:
return "This is a weekend"
case .sunday, .monday, .tuesday, .wednesday, .thursday:
return "This is a weekday"
}
}
Getting Rid of Strings
enum DayType {
case weekday
case weekend
}
func dayType(for day: Day) -> DayType {
switch day {
case .friday, .saturday:
return DayType.weekend
case .sunday, .monday, .tuesday, .wednesday, .thursday:
return DayType.weekday
}
}
func isNotificationMuted(on type: DayType) -> Bool {
switch type {
case DayType.weekend: return true
case DayType.weekday: return false
}
}
func move(_ direction: Direction) {
// Enter your code below
switch direction {
case .up: location.y += 1
case .down: location.y -= 1
case .right: location.x += 1
case .left: location.x -= 1
}
It's better to do a little bit here and there than loads in one go, hence why I'm splitting the first section of this course into two parts. This means that there will probably be around 6 blogs for this particular course, which is fine! I may do the second part later, but there's no urgency to. I've found a good routine for doing this 'bit at a time', allowing the knowledge to sink in. With the whole enum thing becoming ever clearer, it's made me think about my F1 game. In that, I would have at a corner, several different possibilities: for there to be DPs paid, off track or no problem. Each of these could be cases of an Enum, so the string doesn't have to be typed in!
There will be many more examples within that game, and other ideas I'm sure. For now, I'm going to leave enums. The key takeaways are that they are for finite sets of data (days of week, months of year, outcomes from corner etc.), use the UpperCamelCase, but lowerCamelCase for the cases. The enum can be switched within a function or elsewhere, they reduce the chance of errors and give set options for coding. There are shortcuts with the syntax - not using 'case' every time, but writing a list; using just .then the case, rather than the Enum.case each time. Next time, there will be two more videos and two more challenges, including how they link to Methods...
Comments
Post a Comment