POP vs. OO: The differences

- [Instructor] We can model the same system with protocols or with super classes. Yet protocols provide more flexibility. They are all about abstraction. Protocols tell conforming types what to do rather than how to accomplish a certain functionality. With a protocol oriented approach we can create more granular designs that are easier to maintain and enhance. Let's summarize the main differences between the protocol oriented design and the object oriented way of designing the software system.

Subclasses may inherit unnecessary functionality and data from the super class. The internals of super classes get exposed through inheritance which leads to unnecessary complexity being shared with classes. With protocol conformance we get loose coupling. In a protocol oriented design the inheritance hierarchies are replaced by protocol conformance. The protocol oriented design promotes loose coupling between types. Unlike with sub classing types don't inherit unnecessary functionality or data.

They only receive the methods and properties declared in the protocol. Single inheritance can lead to monolithic super classes. With protocol oriented design, types can conform to multiple protocols. Resulting in a more granular design. Inheritance only works with classes. Whereas protocols also support value types. Class instances are passed as references. They get automatically shared upon assignment or when passed as an argument to a method.

We should decide on a case by case basis whether we need this behavior or not. Know that automatic sharing can lead to all kind of bugs and issues. For example one of the receivers may inadvertently modify the shared instance. We may easily end up in concurrency problems if our reference is shared across multiple threads. We can try and handle these problems by copying and adding locks just to add up in producing different bugs and performance issues.

There is no automatic sharing of mutable state with value types since values types are copied upon assignment or when passed to a method or function we avoid unintended changing of shared data and threading issues. You should always consider using value types over classes. So we should start designing our system using a protocol oriented approach and value types. However there are still cases when classes that is reference types, have their place.

At times we need the shared mutable state. We don't want the automatic copy behavior instead we do need to preserve the identity of the original instance and share the same reference across components and method calls. Consider for example an object which is supposed to act as a common dispatcher. It has to collect all the commands filed by the various components, place them in a queue, and execute them as resources become available.

If the dispatcher were a value type it would end up having multiple isolated copies with no way to synchronize the execution of commands sent by the various components. Also we should not fire the type system. With swift three the foundation types have been migrated to value types. However in cocoa and cocoa touch we still encounter classes. As we're relying on their APIs and types it doesn't make sense, and there is no way, to fight the type system.