<story><title>How I Learned to Stop Worrying and Love the State Machine</title><url>http://raganwald.com/2018/02/23/forde.html</url></story><parent_chain><item><author>hprotagonist</author><text>Eric Lippert&amp;#x27;s &amp;quot;Wizards and Warriors&amp;quot; blog posts seem appropriate here, especially as an example of how tracking state and OO can clash pretty badly.&lt;p&gt;&lt;i&gt;A common problem I see in object-oriented design is:&lt;p&gt;A wizard is a kind of player.&lt;p&gt;A warrior is a kind of player.&lt;p&gt;A staff is a kind of weapon.&lt;p&gt;A sword is a kind of weapon.&lt;p&gt;A player has a weapon.&lt;p&gt;But before we get into the details, I just want to point out that I am not really talking about anything specific to the fantasy RPG genre here. Everything in this series applies equally well to Papers and Paychecks, but wizards and warriors are more fun to write about, so there you go.&lt;p&gt;OK, great, we have five bullet points so let’s write some classes without thinking about it! What could possibly go wrong?&lt;/i&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;27&amp;#x2F;wizards-and-warriors-part-one&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;27&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;30&amp;#x2F;wizards-and-warriors-part-two&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;30&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;04&amp;#x2F;wizards-and-warriors-part-three&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;04&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;07&amp;#x2F;wizards-and-warriors-part-four&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;07&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;11&amp;#x2F;wizards-and-warriors-part-five&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;11&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;</text></item></parent_chain><comment><author>keithnz</author><text>I think a lot of bad things happened when the advice around how to determine classes started by looking at the nouns in the problem domain.&lt;p&gt;OO is fundamentally about messaging not abstract data types.  So if you start your design from trying to determine ADTs instead of trying to work out the kinds of message conversations that need to go on you end up with mess of types.&lt;p&gt;In the wizards and warriors we see a large amount of modelling of a domain with rules.  But we, even at the end, still have little idea of what messaging is going to be going on, there is a hint about attacking werewolves.  But we&amp;#x27;ve already made a lot of assumptions about what our first class entites are.  Often what can happen is we find, while we thought we modelled it ok and even sorted out a rule based system, it still seems difficult for our objects to have conversations.&lt;p&gt;maybe what would be better is some thing that can attack other things and wizards, weapons, and warriors are all simply modelled by some composable set of stat modifiers.</text></comment>
<story><title>How I Learned to Stop Worrying and Love the State Machine</title><url>http://raganwald.com/2018/02/23/forde.html</url></story><parent_chain><item><author>hprotagonist</author><text>Eric Lippert&amp;#x27;s &amp;quot;Wizards and Warriors&amp;quot; blog posts seem appropriate here, especially as an example of how tracking state and OO can clash pretty badly.&lt;p&gt;&lt;i&gt;A common problem I see in object-oriented design is:&lt;p&gt;A wizard is a kind of player.&lt;p&gt;A warrior is a kind of player.&lt;p&gt;A staff is a kind of weapon.&lt;p&gt;A sword is a kind of weapon.&lt;p&gt;A player has a weapon.&lt;p&gt;But before we get into the details, I just want to point out that I am not really talking about anything specific to the fantasy RPG genre here. Everything in this series applies equally well to Papers and Paychecks, but wizards and warriors are more fun to write about, so there you go.&lt;p&gt;OK, great, we have five bullet points so let’s write some classes without thinking about it! What could possibly go wrong?&lt;/i&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;27&amp;#x2F;wizards-and-warriors-part-one&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;27&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;30&amp;#x2F;wizards-and-warriors-part-two&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;04&amp;#x2F;30&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;04&amp;#x2F;wizards-and-warriors-part-three&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;04&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;07&amp;#x2F;wizards-and-warriors-part-four&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;07&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;11&amp;#x2F;wizards-and-warriors-part-five&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ericlippert.com&amp;#x2F;2015&amp;#x2F;05&amp;#x2F;11&amp;#x2F;wizards-and-warriors-part...&lt;/a&gt;</text></item></parent_chain><comment><author>munificent</author><text>I love this series. One little rule I&amp;#x27;ve stumbled onto over the years that this series revolves around is:&lt;p&gt;&lt;i&gt;When I&amp;#x27;m stuck on a software design problem, pick some random part of the program and see what happens if I make it first class.&lt;/i&gt;&lt;p&gt;In this case, Eric takes the game rules and turns them into objects. (Essentially the Command pattern[1], which is close to my heart[2].)&lt;p&gt;You can go overboard with this, of course, but I&amp;#x27;ve found time and again if it seems like I can&amp;#x27;t get my code to hang together, it&amp;#x27;s usually because I&amp;#x27;m missing a noun — a reification of some part of my problem that I can pass around and do stuff with.&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Command_pattern&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Command_pattern&lt;/a&gt;&lt;p&gt;[2]: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;gameprogrammingpatterns.com&amp;#x2F;command.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;gameprogrammingpatterns.com&amp;#x2F;command.html&lt;/a&gt;&lt;p&gt;PS: Another solution to Eric&amp;#x27;s initial problem with warriors, wizards, swords, and staves is to be more precise about what capability Player has. If Warriors can only wield Swords and Wizards can only wield Staves, then it&amp;#x27;s &lt;i&gt;not&lt;/i&gt; the case that Player&amp;#x27;s Weapon field can be set with any weapon.&lt;p&gt;So one option is to make Weapon an abstract getter in Player. Then add setters and fields in Wizard and Warrior for the specific types. If all you have is a Player, you can see what their wielding, but not change it. Then, to wield something, you need to know what kind of player you&amp;#x27;re dealing with first.&lt;p&gt;Of course, that doesn&amp;#x27;t scale very well to lots and lots of business rules as in later in the series. But it works if you have a relatively small number of constraints in your subclasses — you just push them up such that the superclass API only exposes the intersection of all of the subclasses&amp;#x27; allowed operations.</text></comment>