Today marks the conclusion of our first three consolidation days in the 100 Days of Swift challenge. Looking over the agenda for the day it looked like a relatively easy day with minimal additional material to be covered. Given that I am still six days behind schedule this looked like the perfect day to maybe squeeze in another to get caught up. The old adage of “Don’t judge a book by its cover” and “Nothing is ever as simple as it looks” would definitely come back to haunt me.
The first section today dealt with properties. This is a fairly straight forward concept of defining variables and constants that are associated with Classes and Structures. Think of these as attributes of an object. For example, we could have a Class called Person and the properties could be things such as gender, eye color, hair color, or clothing. These are all attributes that describe a person. Notice I didn’t list number of eyes, number of ears, or number of toes. While those too are attributes, they don’t really help to describe an instance of Person since those will likely be the same for all people with rare exception.
Also remember, the list of properties does not have to be exhaustive. In so many cases during the design of an application we go overboard in describing objects or classes introducing complexity and for lack of a better term, data glut, where we go into too much detail for what we need. As my experience grows, I am trying to err on the minimum number of properties during design and first-pass coding only adding additional properties or descriptors as needed. It’s easier to go back to a Class and add a property when the need arises than it is to go back and reduce after you find you are not really using some properties that you initially created.
The video on Properties that Paul Hudson gave included an aspect that I had forgotten and must admit have not used as much as perhaps I should have especially in some of my more interactive applications. Swift has incorporated what they describe as Property Observers. These are called when a property is about to be changed or has just been changed and are called with the key words willSet and didSet.
At first these seemed simplistic and I wondered why would you ever use these but the more I thought about them the more ingenious they became. Let’s use our person example from above. We have the property of hair color as part of our attributes. Suppose as we are defining people we notice that our friend Betty was naturally a brunette but for some reason decided that “gentlemen prefer blonds” and goes to her hairdresser and has her hair color changed.
Using the property observer willSet, we could have our application print out that Betty is changing her hair from the old value (Brunette) to the new value (Blond). Likewise you could use the property observer didSet to send a message when a value changed from the old value to the new value. Either works, it just depends on whether you want to notify the user before or after the change. Granted we could have created comparison functions and send messages depending on the comparison but using property observers is easier and the code is more understandable.
These are the small details that sometimes get overlooked when learning foundational concepts but are available to explore as you review a concept after gaining additional context with other code constructs. So as you review your code or attempt to learn new things make sure you step back and consider how they can be incorporated into your own ideas to make you a better programmer.
0 Comments