[swift-users] Comparing POP to OOP
hoffman.jon at gmail.com
Sat Mar 5 16:15:34 CST 2016
> On Feb 25, 2016, at 7:38 PM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
> on Mon Feb 15 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:
>> Thank you for the feedback however you cannot design the code as you
>> describe, if I understand your explanation correctly, because one of the
>> requirements is the animals may be apart of multiple categories. As the
>> example in the post shows the alligator belongs to both the Land and the
>> Sea categories. In you description that would mean that the Alligator type
>> would need to be a subclass of both the Land and Sea superclasses which is
>> not permitted. Remember that one of the drawbacks with OOP is a subclass
>> can only inherit from one superclass.
> That's true in Swift, but not in all realizations of OOP. If your
> article is merely using protocols to get the benefits of multiple
> inheritance from abstract classes, it may not touch at all on what
> differentiates OOP from POP at a fundamental level.
You are absolutely correct; with protocols we do gain a lot more than just multiple inheritance. In this post I touch on protocol composition and also extensions just to name two of them. One of the things that I do emphasize when I talk about Protocol-Oriented programming is it is about so much more than just the protocol.
To be honest, I think that Apple may have done a disservice to POP by giving it the name “Protocol-Oriented Programming”. With OOP and POP having such similar names, people tend to relate them together and in my opinion, how you design your application with POP is fundamentally different than with OOP. Hopefully I will be able to write some additional posts about designing applications in a POP way using case studies. Just a matter of finding time.
In one of the e-mails about this post, someone mentioned Entity-Component Systems (https://en.wikipedia.org/wiki/Entity_component_system). I personally have not used ECS however from what I read from the links provided in that e-mail, in a lot of ways the design philosophy behind POP seems to be closer to ECS than OOP
>> On Mon, Feb 15, 2016 at 1:17 PM, Daniel Tartaglia <danielt1263 at gmail.com>
>>> (Reposting because I forgot to change the subject line. Hope that this is
>>> the correct thing to do.)
>>> I have to say John that I am not a fan of your OOP code. I would have
>>> written the OOP code very much like you wrote the POP version using the
>>> Strategy pattern.
>>> | | |
>>> [Land] [Sea] [Air]
>>> (View the above with a mono-spaced font.)
>>> In essence, I see no difference. There may be a difference, but I don’t
>>> think your example presents one.
>>> On Feb 15, 2016, at 1:00 PM, swift-users-request at swift.org wrote:
>>> Date: Sun, 14 Feb 2016 18:59:05 -0500
>>> From: Jon Hoffman <hoffman.jon at gmail.com>
>>> To: swift-users <swift-users at swift.org>
>>> Subject: [swift-users] Comparing POP to OOP
>>> Message-ID: <5DA5F8F5-D645-4BF9-A0CE-1AF1DB8B3735 at gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>> Numerous tutorials that I have seen take a very Object-Oriented approach
>>> to the protocol-oriented programming (POP) paradigm. By this statement I
>>> mean that they tell us that with POP we should begin our design with the
>>> protocol rather than with the superclass as we did with OOP however the
>>> protocol design tends to mirror the superclass design of OOP. They also
>>> tell us that we should use extensions to add common functionality to types
>>> that conform to a protocol as we did with superclasses in OOP. While
>>> protocols and protocol extensions are arguably two of the most important
>>> concepts of POP these tutorials seem to be missing some other very
>>> important concepts.
>>> In this post I would like to compare Protocol-Oriented design to
>>> Object-Oriented design to highlight some of the conceptual differences.
>>> You can view the blog post here:
>>> http://masteringswift.blogspot.com/2016/02/pop-and-oop.html <
>> swift-users mailing list
>> swift-users at swift.org
> swift-users mailing list
> swift-users at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-users