[swift-users] Comparing POP to OOP

[Jon Hoffman]

Sorry for the misunderstanding, I see what you are doing now, you are using
the command pattern, however I so see quite a bit of difference between
your design and my POP design.  The biggest is the number of types needed
between the designs.  For example, how the Lion attacks and moves on land
is different than how the Alligator attacks and moves on land therefore you
will need separate attack and movement types for each type of animal.   This
means that you will need a Alligator type and to go with that Alligator
type you would need AlligatorLandAttack, AlligatorSeaAttack,
AlligatorLandMove and AlligatorSeaMove types.  You would also need the Lion
type with a LionLandAttack and LionLandMove type.  You would need these
separate types for each animal you create.  With my POP all of this logic
would be encapsulated in a single types.



By encapsulating all of the logic into a single type your code will be
easier to manage and also less error prone.  For example, in your code
there is nothing preventing a developer to accidentally adding the
LionLandAttack type to the Alligator type and since that error could occur
anyplace where an instance of the Alligator is created it could also be
hard to track down.



One of the principles of Protocol-Oriented programming is making our code
safer and easier to manage.  Your code would work but I would still say
that the POP code would be much easier to manage long term and would also
be less error prone.  That is my opinion and everyone will have their own.

On Mon, Feb 15, 2016 at 1:52 PM, Daniel Tartaglia <danielt1263 at gmail.com>
wrote:

> That’s easy to do by allowing an Animal to hold multiple modes. Yes, the
> code below uses a Protocol, but only as an OO interface.
>
> let alligator = Animal()
> alligator.mode.append(Land())
> alligator.mode.append(Sea())
>
> protocol Mode {
>     func attack() -> Bool
>     func move() -> Bool
> }
>
> class Animal {
>     var modes: [Mode]
>     func attack() -> Bool {
>         for mode in modes {
>             if mode.attack() {
>                 break
>             }
>         }
>     }
> }
>
>
>
> On Feb 15, 2016, at 1:43 PM, Jon Hoffman <hoffman.jon at gmail.com> 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.
>
> Jon
>
> On Mon, Feb 15, 2016 at 1:17 PM, Daniel Tartaglia <danielt1263 at gmail.com>
> wrote:
>
>> (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.
>>
>> [Animal]<*>--->[Mode]
>>                   ^
>>                   |
>>            +------+------+
>>            |      |      |
>>         [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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160215/e88d8f63/attachment.html>