Treehouse Intermediate Course Part 9 (Access Levels and APIs)
Yes another one! That does that make it 5 in a row?! Anyway, today will be fairly brief as there's not much on this course. Then it will mean Intermediate Treehouse complete! I feel like I've got to grips well with certain concepts but am frustrated there wasn't more in practice. Once this is done I will be having a look over the Udemy ones. Right, onto Access Levels!
Time started: 16:15
Access Control
This is about restricting access to code in other files etc.
So this links to Module.
E.g. import Foundation etc.
Whereas a swift file (ending in .swift) are source files.
Open and Public access.
UI View Controller - this has open access.
Within a module, open and public function in the same way. Open is the least restrictive. Then public, then internal access. Internal access is the default level of access. Then it is 'file private'. You can reduce the access. Private is least open.
So a private stored property can only be used within its class.
Defining Access Levels
You cannot define an entity in terms of another entity that has a more restrictive access level.
So all of the keywords are as described above. Just to clarify...
Open
Public
Internal
fileprivate
private
For custom types, this goes in front of the declaration - and the same for functions, methods etc.
So declaring a class as private would mean that all of the members (properties) would be private by default. So you can't have a public method inside a private method.
BUT you can have a more restrictive access level inside a type. E.g. you could have a private method within a public class.
Subclassing - A subclass can not have a higher access level of a base/super class.
You can override any class member as long as it is visible.
So when coming across other people's code, you need to be aware of these keywords and what it all means. Open and public code is accessible to us, whereas the others are not!
Open and public are the same access level within the same module.
You CANNOT subclass a public class.
Right, so that was brief. Quite confusing but no need to worry about it for now! That's ALL of Intermediate Swift done. Not much to it really - just a few hours worth altogether. I'm going to stop there, but I've actually bee taken to another 'beginner' course - API guidelines. It makes sense to do this as I haven't yet; hopefully it will be practical and useful. And there are two more course for Intermediate Swift - Generics and Closures! These seem important and fundamental, so actually there's another couple of weeks worth!
I'm actually going to continue and crack on with the API stuff as the access control was so brief. Here goes!
Time: 16:35 (20 minutes so far)
Why do we Need Guidelines?
APIs - application programme interfaces
So basically there were a lot of inconsistencies. Prior to Swift 3 there weren't really any specific guidelines. The new guidelines means my swift code will look like everyone else's!
This will be useful as I started learning in April 2015 - back when Swift 1 was still in use!!
Pasan makes the point of not needing to change style completely and that we'll get used to all of the rules eventually.
Point of Use - when we write methods - when we call them is more important than how we define them. Huh?
Clarity over Brevity - so people started writing shorter code. Not so in Swift - we want to understand better so making it as clear as possible.
Naming Types
Key rule - names of properties, types and constants should read as NOUNS.
e.g. class NetworkManager - not clear - what does this object do?
There are of course exceptions. Bools. isEmpty/contains are good examples.
'is' is a great way to start the property name.
6/6 on the quiz! Had to do one question again though as I misread it.
Time: 16:50 (15 minutes)
Total time today: 35 minutes
35 minutes - that's good! Little and often is best at the moment. I've picked up some key things here about access levels and APIs. Not much done in practice but some good conceptual bits. It's been reassuring to see that there are several more courses here, plenty more to focus on to improve my understanding. Nothing is too great a conceptual jump, whereas had I gone straight from beginner to intermediate, it would have been. When I have finished APIs, it will be closures and generics to work through. At that point I may be putting Treehouse on pause. OK, that's all for now!
Time started: 16:15
Access Control
This is about restricting access to code in other files etc.
So this links to Module.
E.g. import Foundation etc.
Whereas a swift file (ending in .swift) are source files.
Open and Public access.
UI View Controller - this has open access.
Within a module, open and public function in the same way. Open is the least restrictive. Then public, then internal access. Internal access is the default level of access. Then it is 'file private'. You can reduce the access. Private is least open.
So a private stored property can only be used within its class.
Defining Access Levels
You cannot define an entity in terms of another entity that has a more restrictive access level.
So all of the keywords are as described above. Just to clarify...
Open
Public
Internal
fileprivate
private
For custom types, this goes in front of the declaration - and the same for functions, methods etc.
So declaring a class as private would mean that all of the members (properties) would be private by default. So you can't have a public method inside a private method.
BUT you can have a more restrictive access level inside a type. E.g. you could have a private method within a public class.
Subclassing - A subclass can not have a higher access level of a base/super class.
You can override any class member as long as it is visible.
So when coming across other people's code, you need to be aware of these keywords and what it all means. Open and public code is accessible to us, whereas the others are not!
Open and public are the same access level within the same module.
You CANNOT subclass a public class.
Right, so that was brief. Quite confusing but no need to worry about it for now! That's ALL of Intermediate Swift done. Not much to it really - just a few hours worth altogether. I'm going to stop there, but I've actually bee taken to another 'beginner' course - API guidelines. It makes sense to do this as I haven't yet; hopefully it will be practical and useful. And there are two more course for Intermediate Swift - Generics and Closures! These seem important and fundamental, so actually there's another couple of weeks worth!
I'm actually going to continue and crack on with the API stuff as the access control was so brief. Here goes!
Time: 16:35 (20 minutes so far)
Why do we Need Guidelines?
APIs - application programme interfaces
So basically there were a lot of inconsistencies. Prior to Swift 3 there weren't really any specific guidelines. The new guidelines means my swift code will look like everyone else's!
This will be useful as I started learning in April 2015 - back when Swift 1 was still in use!!
Pasan makes the point of not needing to change style completely and that we'll get used to all of the rules eventually.
Point of Use - when we write methods - when we call them is more important than how we define them. Huh?
Clarity over Brevity - so people started writing shorter code. Not so in Swift - we want to understand better so making it as clear as possible.
Naming Types
Key rule - names of properties, types and constants should read as NOUNS.
e.g. class NetworkManager - not clear - what does this object do?
There are of course exceptions. Bools. isEmpty/contains are good examples.
'is' is a great way to start the property name.
6/6 on the quiz! Had to do one question again though as I misread it.
Time: 16:50 (15 minutes)
Total time today: 35 minutes
35 minutes - that's good! Little and often is best at the moment. I've picked up some key things here about access levels and APIs. Not much done in practice but some good conceptual bits. It's been reassuring to see that there are several more courses here, plenty more to focus on to improve my understanding. Nothing is too great a conceptual jump, whereas had I gone straight from beginner to intermediate, it would have been. When I have finished APIs, it will be closures and generics to work through. At that point I may be putting Treehouse on pause. OK, that's all for now!
Comments
Post a Comment