use Perl

• Class layout (Score:1)

  by jhannah (5254) <{jay} {at} {jays.net}> on 2004.08.22 21:41 (#33613) Homepage Journal

  At a glance, if I was going to design the class structure you were looking for, I'd start with something like this:

  - Character
    - Race
      - Elf (@ISA InfraVision)
        - Drow
      - Human
      - Dwarf
    - Class
      - Thief (sub pick_pocket)
      - Magician
  
    - ElvenThief (@ISA Elf, Thief)
    - DwarfThief (@ISA Drawf, Thief)
  
  - Skills (contains defaults skill level settings)
    - Vision
      - InfraVision
     - Theft
        - PickPocket

  I don't see why you'd need mixin's. In my Perl5 mentality I think I could handle whatever method and attribute polymorphism were needed to get the job done.

  Regardless, though, I'm not sure why you'd write up this class structure anyway. When it comes to skills and/or attributes, all races and classes can attempt to pick_pocket, swim, cast_spell, run, sleep, whatever. They just all have different statistical chances of success when trying to pull off whatever task you had in mind.

  Seems to me that when actually sitting down to write an app along these lines, you'd have a full default matrix of statistics for any given character, and the races/classes/exp, etc would simply tweak the default statistics up or down, depending. I'm not sure how OO would really serve a useful purpose for character behavior control. Magicians *can* pick_pocket, they'll just fail and immediately call for a cleric, as you point out. So, you need every method available to every character anyway.

  $0.02,

  j

  --
  Omaha Perl Mongers [pm.org]

  Reply to This

  • Re:Class layout (Score:2)

    by Ovid (2709)

    With all due respect, I think you've inadvertently illustrated my point. Let's stick with Perl 5 and assume that delegation is the key to performing profession-specific behavior, but we won't use delegation yet. We'll assume four races, human, elf, dwarf and halfling. We'll also assume four professions, fighter, thief, magician and cleric. With the Character and Profession abstract base classes, we have a grand total of ten classes, each which encapsulates the basic attributes of what they're trying to m
    • Re:Class layout (Score:1)

      by jhannah (5254)

      1) I agree that a class structure for each class / race would get way out of hand. I fail to understand why you need a class structure to handle the problem in the first place. It seems to me that every character could attempt any behaviour, so you could just have a default set of skill levels, and perform procedural adjustment to those stats based on classes/races. I have no idea what methods / attributes would useful in individual class / race classes.

      2) If the class structure *is* needed for some reaso

      --
      Omaha Perl Mongers [pm.org]
      • Re:Class layout (Score:2)

        by Ovid (2709)

        Those are valid questions. The truth is, you never need objects to accomplish any programming problem. I chose objects for this illustration primarily because characters are really bundles of data with behaviors attached to them. This, of course, is one way objects are defined.

        As for how mixins solve the problem more elegantly, you might want to read a virtually identical node on Perlmonks [perlmonks.org]. In light of the responses, I back off a bit from asserting the utility of mixins once it became clear that they'