Instruction 2

In the last demo, you updated ContactCard to support marking the contact as a company by setting the value of isCompany to true on the contact object after creating it. You also updated addRelatedContact(_:) to compare the values of isCompany between the two contacts and only apply the second relationship only if the two contacts are companies or people. You also cleaned up the implementation of that function right away as soon as you saw room for improvement.

Its always important to look at the code you are writing with a judgmental eye. There will be many occasions that you’ll get the feeling of “This looks a little messy” and in many cases that feeling will be valid and there will be a way to clean it up a little.

But please note, you can always strive to make your code look cleaner, but just like everything “Perfect is the enemy of good”. You must pay attention to what are you improving and why it falls short because otherwise you may end up over engineering your system which can be much much worse than messy code.

Notice that the way you are marking a contact as a company is by performing a second step which is to set isCompany to true. This works but isn’t ideal because you are exposing additional details of ContactCard to whoever is using it in your system to get the functionality of the “Company” support. Additionally, you have a small issue in the implementation of addRelatedContact(_:) where if you execute ehabContact.addRelatedContact(kodeco) it’ll work and create a one-way relationship. This means you need to add additional logic in that function that only applies if the method is called on a person contact.

It would be cleaner to create a company contact in one step and separate the validation logic between a person contact and the company contact.

Inheritance in OOP is an excellent solution for challenges like this.

When you look at the street, you can see so many different kinds of vehicles, there are busses, trains, cars, motorcycles, bicycles, …etc. They are all means of transportation and move different number of people from one place to another. Moreover, each of those types of vehicles have different models that can group certain characteristics together. Then each individual car has differences to the others based milage, maintenance and any customization applied by the owner.

In code, you can create a class named Vehicle and have all the common information and methods/operations defined inside it. Even if the different vehicles actually perform those operations differently. So while a bike and a truck behave differently, both is a kind of vehicle that can move and stop.

To specify vehicle types such as a car, you can create a subclasses that inherit from Vehicle. Hence, the Train, Car, and Motorcycle classes all inherit from the Vehicle. They also provide their own behavior.

While a Train class can move and stop, it can also announce the upcoming station. The Car can open its trunk and the Motorcycle can open its side stand. All three classes are different, yet all three are still vehicles.

Additionally, cars are made by multiple manufacturers that affect how the vehicle behaves. To model this in code, you can create a subclass specific to the manufacturer’s brand. In subclasses of the brand will inherit those traits.

A car defined from an instance of Volvo will have all the properties and methods defined in Car and all the ones defined in Vehicle.

To match this approach with your program, You’ll need to create the two new types PersonContactCard and CompanyContactCard where the customizations specific to their types will be implemented. Both of them inherit from ContactCard that will contain all the common functionality and properties they both have.