What is the difference between extends and implements?
This is a problem that many people that are new to the language run into, even if they are experienced programmers, especially if they have no experience in Object Oriented Programming. Both terms are keywords for inheritance, but the difference is in what it inherits from. Extends implies that the class mentioned is a class with data and methods. This means that the child class in this case is gaining bits of code from that parent class. Implements implies that the class mentioned is an interface that may have data fields and method names, but no implemented code in it. If you are familiar with Object Oriented Programming, these terms should make some bit of sense now. An easy way to remember this is you would only extend something that already has some size to it. You wouldn't consider "extending" a deck that isn't built yet.
When you start a current iOS project now, how do you pick which language to use between Objective-C and Swift?
This really depends on what the project is and its complexity. As a general rule, if I am going to want to do something very simple, I choose Objective-C. The syntax is much like C++ which I started programming with and I am the quickest writing code in. If I am planning on using sensors and the more advance capabilities of iOS devices, I choose Swift. Swift makes it very simple to pull data from the device and in its current version, it is very fast and easy to read and write.
What is the biggest no-no when it comes to inheritance, more specifically multiple inheritance?
The biggest concern that exists when you are attempting to implement multiple inheritance to ensure that you do not have a Diamond of Death! This is when a single class has 2 or more child classes, and at least 2 of those children are then inherited by another single class, as seen below. ParentClass / \ / \ / \ ChildClass1 ChildClass2 \ / \ / \ / GrandchildClass This issue is not even allowed in some Object Oriented programming languages, but in C++, this is not restricted at all. The danger from this structure comes from naming conflicts and ambiguity of implementations. Methods that are inherited from the ParentClass and then implemented in both ChildClass1 and ChildClass2 are now both methods to GrandchildClass with no way to distinguish between the two implementations. I always try to stress to my students to stay away from this structure all together, but if absolutely necessary, I emphasize to map out their classes in a UML diagram, plan on where to implement all methods, and do not allow any ambiguity.