Inherently Classic

So here I am ending the first week of Flatiron with little structure and my mind is constantly thinking about my next class. But I’m optimistic none the less about being able to use what was learned. I’ve dabbled in the language C++ before joining Flatiron School for iOS development and by dabbled I mean I dove head first in to a endless road of, ‘man I really suck at this.’

But I feel like those experiences have prepared me for what will be the life of a programmer, feeling of frustration and annoyances. Fortunately for me, I have already gone through the 10+ hour error (it was a semicolon.. of course), and uninformative error messages. I now CAN debug my swift errors, usually… (//thanks Jim!) But there was one thing that really got to me when I was learning C++. That was Class Inheritance and oh boy…. that was… oh boy. The struggle was real, abstraction this abstraction that. Pointers here, references there, don’t understand? Too bad! Figure it out if you want to continue.

I didn’t have any wonderful learn.co labs to teach me, (//thanks Jim!) only Google and a lot of time testing if things worked the was I expected. I learned it after what felt like a year, but was actually only two months to wrap my head around it. But lets not mull over the past, what does all that have to do with Swift? (//not an optional, we good here Johann)

I wanted to see if Swift followed the same inheritance/override rules as C++ does, so I opened a playground, played in and well… I’ll explain the whole deal.

Lets say I have a ‘class Animal’. This Animal has some properties and a method named ‘eat()’. So if i create an instance of Animal named ‘animalCreature’, i can now access eat() simply by typing :

‘animalCreature.eat()’

Now lets say we want to make something that inherits Animal.

class Dog : Animal {

Dog inherits Animal and all of Animal’s properties and functions. The powerful thing about inheritance truly shines at this point in time. The instance of Animal we made before can now be reused.

animalCreature = Dog()

That works because Dog inherits Animal and so animalCreature can reference Dog. However, using the eat() method will do what ever Animal defined it as and not as how a Dog should eat(). We can override the eat() method in the Dog class and define it differently. What happens now is when animalCreature uses the eat() method, the Dog class version of eat() will be called. Awesome! We knew that thanks for nothing?! Wait wait wait, almost to my point(er*) i promise.

What if Dog has an extra method called rollOver() ? Do you think animalCreature will be able to use that method?

No, nope, nada. So wait… an instance of base class referencing a inherited class can only do what ever was available in base class? THAT is how we get overly large base classes and how God classes come about. Because developers try to jam everything in to that base class.

Fortunately for us, there are some ways to work around it. Every new property or method that an inherited class has can still be used as long as it is contained with in some override method of the inherited class.

class Dog : Animal {
override func eat() {
rollOver()
}
func rollOver() {
}

So now calling animalCreature.eat() will also do the rollOver() method. But… that seems pointless and useless and why would you rollOver while eating?

Thats besides the point! It is to show that there are certain cases where inheritance doesn’t do what you really want with out bending head over heels. What I’ve have learned is that Swift still has those core values of C rooted deep inside its program. With this new knowledge and my short background in C++, it is almost comforting to know that I still hate classes regardless of syntactic sugar or not.

For (slightly) more detailed information on classes and inheritance, check out the link below.

https://github.com/bensu1013/Inherently-Classy

Show your support

Clapping shows how much you appreciated Ben Su’s story.