Sandra L Course Part 5 (lectures 30 to 39)
Well 3 days is better than the gap between the previous entries! My plan is to work through OOP today, then start working on my next independent app project. Let's go!
Start Time - 10:50
Object Oriented Programming
My take - this is about the creation of 'object's which are an instance of a particular class or type. There is functionality involved in this too. Let's see the actual definition!
So data vs action is a key part.
Procedural oriented programming - design program with a set of instructions. I get this as procedural text types/instructions is something I've taught.
Data types - strings, ints etc. but also custom ones from classes/structs
Coffee machine example -
A good analogy for the fact that the machine has different functions and specifications (properties).
The above are the functions.
Engineers build the actual machine - it has specifications. It then has the propensity for different jobs/functions.
An object is a coffee machine made with those specifications! It follows the blueprint of the class.
Classes and Objects
Another example of a car/vehicle.
The class describe the characteristics and what type of actions it can perform.
The object is the END PRODUCT.
All that is fine and conceptually clear to me (CCTM!).
Class Vehicle
Basic template for any class -
So the DIFFERENT property I want is to show if it is has an open rooftop. That needs to be added into the code!
Start Time - 10:50
Object Oriented Programming
My take - this is about the creation of 'object's which are an instance of a particular class or type. There is functionality involved in this too. Let's see the actual definition!
So data vs action is a key part.
Procedural oriented programming - design program with a set of instructions. I get this as procedural text types/instructions is something I've taught.
Data types - strings, ints etc. but also custom ones from classes/structs
Coffee machine example -
A good analogy for the fact that the machine has different functions and specifications (properties).
The above are the functions.
Engineers build the actual machine - it has specifications. It then has the propensity for different jobs/functions.
An object is a coffee machine made with those specifications! It follows the blueprint of the class.
Classes and Objects
Another example of a car/vehicle.
The class describe the characteristics and what type of actions it can perform.
The object is the END PRODUCT.
All that is fine and conceptually clear to me (CCTM!).
Class Vehicle
Basic template for any class -
class Vehicle {
//properties
//methods
}
So properties put in and init set up.
class Vehicle {
//properties
let colour: UIColor
let numWheels: Int
let numSeats: Int
let numDoors: Int
init(colour: UIColor, numWheels: Int, numSeats: Int, numDoors: Int) {
self.colour = colour
self.numWheels = numWheels
self.numSeats = numSeats
self.numDoors = numDoors
}
//methods
}
//methods
func start() {
print("Vehicle starts")
}
func drive() {
print("Vehicle drives")
}
func brake() {
print("Vehicle brakes")
}
func park() {
print("Vehicle parks")
}
}
func describe() {
if self.colour == UIColor.red {
print("The vehicle is red with \(numDoors) doors.")
} else {
print("The vehicle is not red and has \(numDoors) doors.")
}
}
}
let car = Vehicle(colour: UIColor.red, numWheels: 4, numSeats: 5, numDoors: 3)
OK so extra method of describe added and an object of 'car' created. All of that is fine and clear. CCTM!
Class Inheritance
My take - this is something that was at one point tricky but fine now. It makes sense to create subclasses to inherit the properties and methods. However, some of the syntax can get confusing. There are different rules with the init syntax - using the super keyword from the parent class.
class Convertible: Vehicle {
let hasOpenRooftop: Bool = true
}
let convertible = Convertible(colour: .blue, numWheels: 4, numSeats: 2, numDoors: 3)
So the DIFFERENT property I want is to show if it is has an open rooftop. That needs to be added into the code!
class Convertible: Vehicle {
let hasOpenRooftop: Bool = true
}
No errors or init requirements as I have given IT A VALUE!
class Convertible: Vehicle {
let hasOpenRooftop: Bool = true
func retractRooftop() {
print("Rooftop has been retracted")
}
override func describe() {
if self.colour == .red {
print("This convertible is red with \(numDoors) doors.")
} else {
print("This convertible is not red and has \(numDoors) doors.")
}
}
}
Cool use of override in the above. I did that as soon as she mentioned that the describe function would need some changing.
Pizza Restaurant
So these are all classes for the people!
So I did a lot of screenshots here as I loved how visual the example is! I already have an idea of how I could make this all.
A couple of aspects that will need enumerations - the size (small, med or large) and payment (cash or credit card). Those will need to be made first.
OK enums done and client class made:
enum Size {
case Small
case Medium
case Large
}
enum Payment {
case cash
case creditCard
}
class Client {
let name: String
let phoneNumber: String
let address: String
init(name: String, phoneNumber: String, address: String) {
self.name = name
self.phoneNumber = phoneNumber
self.address = address
}
func makeOrder() {
print("Order has been made")
}
func payOrder() {
print("Order has been paid for")
}
}
Now I will make the classes for the other people then for the pizza and orders...
Right, one thing these three have in common is that they all have names. They can be grouped together as 'Staff'. Basically it means I won't have to do the name and init every time!
class Staff {
let name: String
init(name: String) {
self.name = name
}
}
class PhoneOperator: Staff {
func takeOrder() {
print("Order has been taken")
}
func confirmOrder() {
print("Order has been confirmed")
}
}
class Cook: Staff {
func makePizza() {
print("Pizza has been made")
}
}
class DeliveryGuy: Staff {
func deliverPizza() {
print("Pizza has been delivered")
}
}
That is smart and an example of DRY!
Now for the last bits...
class Pizza {
let type: String
let size: Size
let toppings: [String]
init(type: String, size: Size, toppings: [String]) {
self.type = type
self.size = size
self.toppings = toppings
}
}
That's using the enum of size from before. Last bit now!
Wow - big one!
class Orders {
let date: String
let pizza: Pizza
let client: Client
let paymentType: Payment
init(date: String, pizza: Pizza, client: Client, paymentType: Payment) {
self.date = date
self.pizza = pizza
self.client = client
self.paymentType = paymentType
}
func isPaid() {
print("Payment has been processed.")
}
func isShipped() {
print("Pizza has been shipped.")
}
func isDelivered() {
print("Pizza has been delivered.")
}
func isCompleted() {
print("Order is completed.")
}
}
NOW I can see what Sandra did....
Awesome! One useful thing - Date can be generated by the current date and time - rather than putting this in as a String...
let client1 = Client(name: "Josh", phoneNumber: "0558733737", address: "7 Revell Avenue")
client1.makeOrder()
let pizza1 = Pizza(type: "Italian", size: .Large, toppings: ["Pepperoni", "Onion", "Cheese"])
let order1 = Orders(pizza: pizza1, client: client1, paymentType: .cash)
order1.date
Good stuff.
OK, a cool thing I can do to tweak my 'staff' classes is by putting in objects within different functions. Will show properly in a moment....
class DeliveryGuy: Staff {
func deliverPizza(pizza: Pizza, client: Client) {
print("Pizza has been delivered to \(client.name) at \(client.address)")
}
}
Let's see if that works!
let deliveryGuy1 = DeliveryGuy(name: "Steve")
deliveryGuy1.deliverPizza(pizza: pizza1, client: client1)
Awesome! This is printed:
So this makes it clearer the links between classes.
*Key thing learned is how you put custom types as parameters. They need an OBJECT created for this to actually work! In the above case, I had an object for pizza and client, therefore I could do the deliverPizza function.
So in Sandra's example, she puts more details in and links back to the other values. I could do the same but I honestly get it now - using the other custom class types as the parameters then putting them into string interpolation.
I guess the difference with this and my HowManyLetters app is that the labels/buttons etc. But it does make me want to create more classes in order to simplify my code.
Here's another cool thing that Sandra does with all of the code - sets it up like it is a play!
After some more code and series of instructions, this is the output:
It is like a play! With narrator and speaking parts!
Really cool and I love how it all links together. Nice example Sandra!
Finish Time - 12:
So a good session. REALLY good to explore classes with all the links, especially the aspect of passing through objects into parameters etc. Neat. Later today I am going to start my next own app project!
Comments
Post a Comment