Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

iOS Object-Oriented Swift Class Inheritance Overriding Properties

Zenek Barburka
Zenek Barburka
7,009 Points

The most confusing tutorial so far. You need to do better!

first of all, why would you call the superclass enemy and subclass SuperEnemy, Don't you think it is very confusing? Secondly, When you are talking about need to initialise a property of subclass, why are you adding a property that already has a value and does not need to be included in init (isSuper: Bool = True)? Seriously guys, you need to do much better than that, cause going through this video, trying to distinguish whether super refers to superclass or SuperEnemy is a nightmare. Unless your intention was to confuse us???

I totally agree, in addition as if it wasn't confusing enough, base class is being referred as superclass..

This video needs a remake.

11 Answers

Dave Figueroa
Dave Figueroa
13,912 Points

I also agree. I'm spending most of my time reviewing the documentation and the free eBook just to understand what's going on.

I really don't mind having to do research, but it's surpassing the point where I'm not sure I'm getting anything out of the videos at all - apart from confusion.

Taylor Smith
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Taylor Smith
iOS Development Techdegree Graduate 14,153 Points

yeah... it seems like the jump from unit 1 to unit 2 is quite substantial and moves much much quicker. I'm finding myself after each video thinking "wtf did i just watch" haha

chzevernchong
chzevernchong
2,845 Points

I though i am the one who does not understand the OOP topic until i watched all the comment here....haha..and i wish he stop talking about enemy and tower. It is very confusing, i rather he use different scenario to talk about OOP

Zenek Barburka
Zenek Barburka
7,009 Points

I am relieved to seethat I am not the only one having hard time with these videos. They really require doing lots of additional research in order to grasp basic concepts. It would be ok if they were for free, but since we are paying for them it is not. The bottom line is, the concepts presented in the videos are quite easy, however they way they are presented makes them look as something very complicated

Thomas Andrew
Thomas Andrew
9,295 Points

Why did he name the subclass superEnemy! So confusing. Almost gave up entirely when I heard the word "Super" for the 90th time.

Agreed.

Get rid of the towers and enemies example! It just adds about confusion for newcomers. You should instead focus on the main concepts without generating that much distraction..

Worst video (and overall course) so far.

since the OOP is the basic and important topic, please make it easy, make another example than tower and enemy. it is really really really really confusing for beginner !!!!

Hey, Zenek!

Ah, I totally feel you here. The nature behind called the superclass Enemy and the subclass SuperEnemy is perhaps a bit of a confusing choice of naming. The intention there was to say, here is a default blueprint for an enemy and then we can create more complex enemies from that blueprint. I'd look past the names for these two classes and focus on their relationship to one another. That's the most important part. ?

Adding isSuper outside of the overridden init() method is necessary here because the superclass/parent, Enemy, doesn't have that property. Essentially, when we write override super.init(), we're telling the compiler to focus on this overridden init() method rather than the parent's init() method. Why are we doing that? It's so that we can override the default value of the life property. We don't put isSuper in this overridden init() method because this method is only to override default property values that the parent has. ?

I'd love to stick around and help clarify any of these things further for you! ?

Michelle Harrison
Michelle Harrison
8,782 Points

I'm so glad I found this comment thread if only to know I'm not the only one thinking the Tower and Enemy game concept was a bad choice for teaching OOP to beginners.

I've had to look for some additional sources on learning tuples and structs and found a couple of Medium articles on Swift for beginners and the examples used in those articles are MUCH simpler than this whole Tower and Enemy game. After....actually at this point it's during....every video on Treehouse I'm having to copy and paste the transcription into Word and read through it slowly and repeatedly just to get a basic understanding of what he's talking about. I'm glad I have the transcripts because if not, I'd be completely lost at this point, but it's also taking me double if not triple the amount of time I was expecting to give to each video.

I'm grasping all of the concepts and passing all the tests, but if at this point in the course I'm supposed to be programming a game like that all by myself then I'm screwed lol.

I may be a bit late here, but for everyone having issues retaining the content from this video, try checking out a similar languages videos on inheritance in classes. I had luck with the Python videos. The syntax is slightly different, but the ideas are the same and the videos are much better and easier to follow.

The terminology can be much better and just the theme in general kind of sucks for introductory course. Like someone else mentioned subclass just makes one think that it is less than a superclass and unfortunately that is wrong. I like referring to them as parent and child instead, because then you can kind see the parent as handing things down to the child and the child having the ability to make changes.