Instruction 2

In the last demo, you updated the setters in ContactCard to return a Boolean value representing the success or failure of the update operation. You did this because a new child type required a validation that could reject information, and the base type assumed that all data is saved.

Changing the app’s functionality in a way that the base type doesn’t expect goes against the Liskov Substitution principle. You refactored the contacts app so that it properly follows the principle, reducing the chance of creating unexpected behavior down the road.

Now, you’ll learn about the next SOLID principle: Interface Segregation. The definition of Interface Segregation is:

Clients should not be forced to depend upon interfaces they do not use.

When designing a protocol or interface that you’ll use in different places in your code, it’s best to break that protocol into multiple smaller pieces where each piece has a specific role. That way, clients depend only on the part of the protocol they need.

This principle focuses on the design of protocols. A protocol is a blueprint for a class that doesn’t contain any implementations, only the method definitions. Any class or type conforming to this blueprint must implement all the methods in it.

To understand the principle, start by defining an example of a blueprint for the controls that can exist in a car. These controls could include:

• Driving controls: Steering, acceleration and brakes.
• Navigation system controls: Entering new addresses, choosing routes, etc.
• Radio controls: Setting the station and volume.
• Climate controls: Heating and air conditioner settings.

Imagine you’re developing software for a vehicle controlled by AI. You have modules for AI controls, entertainment, weather control and navigation. Each of these modules must integrate with the car’s system to function properly.

The blueprint for car controls includes methods for all four systems: AI controls, entertainment, weather control, and navigation. However, each system integrates with only its corresponding method and doesn’t require access to or knowledge of the other methods. This is where the Interface Segregation principle comes into play.

In this example, you shouldn’t have one protocol for the whole car; instead, you should have a protocol for each system. You should create four separate blueprints: one each for driving, navigation, radio and climate controls.

You might have a single class that implements all four blueprints, but your AI modules will interact with the car using only the relevant protocol type, remaining unaware of the other blueprint implementations. For example, the weather controls module will only see the methods defined in the climate controls protocol.

In the next demo, you’ll break the definition of a large protocol into multiple smaller ones.