<div dir="ltr">
<p class="MsoNormal">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.<span style="mso-spacerun:yes">
</span>The biggest is the number of types needed between the designs.<span style="mso-spacerun:yes"> </span>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.<span style="mso-spacerun:yes"> </span>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.<span style="mso-spacerun:yes"> </span>You would also need the Lion type with a
LionLandAttack and LionLandMove type.<span style="mso-spacerun:yes">
</span>You would need these separate types for each animal you create.<span style="mso-spacerun:yes"> </span>With my POP all of this logic would be
encapsulated in a single types.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">By encapsulating all of the logic into a single type your
code will be easier to manage and also less error prone.<span style="mso-spacerun:yes"> </span>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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">One of the principles of Protocol-Oriented programming is
making our code safer and easier to manage.<span style="mso-spacerun:yes">
</span>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.<span style="mso-spacerun:yes"> </span>That is my opinion and everyone will have
their own.</p>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 1:52 PM, Daniel Tartaglia <span dir="ltr"><<a href="mailto:danielt1263@gmail.com" target="_blank">danielt1263@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div><font face="Monaco">let alligator = Animal()</font></div><div><font face="Monaco">alligator.mode.append(Land())</font></div><div><font face="Monaco">alligator.mode.append(Sea())</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco">protocol Mode {</font></div><div><font face="Monaco"> func attack() -> Bool</font></div><div><font face="Monaco"> func move() -> Bool</font></div><div><font face="Monaco">}</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco">class Animal {</font></div><div><font face="Monaco"> var modes: [Mode]</font></div><div><font face="Monaco"> func attack() -> Bool {</font></div><div><font face="Monaco"> for mode in modes {</font></div><div><font face="Monaco"> if mode.attack() {</font></div><div><font face="Monaco"> break</font></div><span class=""><div><font face="Monaco"> }</font></div><div><font face="Monaco"> }</font></div><div><font face="Monaco"> }</font></div><div><font face="Monaco">}</font></div><div><br></div><div><br><div><br><div><blockquote type="cite"><div>On Feb 15, 2016, at 1:43 PM, Jon Hoffman <<a href="mailto:hoffman.jon@gmail.com" target="_blank">hoffman.jon@gmail.com</a>> wrote:</div><br><div><div dir="ltr">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.<div><br></div><div>Jon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 1:17 PM, Daniel Tartaglia <span dir="ltr"><<a href="mailto:danielt1263@gmail.com" target="_blank">danielt1263@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>(Reposting because I forgot to change the subject line. Hope that this is the correct thing to do.)</div><div><br></div>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.<br><div><div style="word-wrap:break-word"><div><br></div><div><div><font face="Monaco">[Animal]<*>--->[Mode]</font></div><div><font face="Monaco"> ^</font></div><div><font face="Monaco"> |</font></div><div><font face="Monaco"> +------+------+</font></div><div><font face="Monaco"> | | |</font></div><div><font face="Monaco"> [Land] [Sea] [Air]</font></div><div> </div></div><div><br></div><div>(View the above with a mono-spaced font.)</div><div><br></div><div>In essence, I see no difference. There may be a difference, but I don’t think your example presents one.</div><div><br></div></div></div></div></blockquote></div></div></div></blockquote></div><br></div></div></span></div></blockquote></div><br></div>