Ruby Scripting

[kyonides]

More About Parent Classes

Tonight I guess I should tell you a bit more about parent classes and why you need them.

Do you really need them?

As I told you before, or at least I should have done so back then, that depends on your very personal design. Some people never use them while others do on a daily basis. So you're gonna learn when you should use them or just skip them if there's no use in creating them in the first place.

Code:

class Rect
  def initialize(x, y, w, h)
    @x = x
    @y = y
    @width = w
    @height = h
  end
  attr_accessor :x, :y, :width, :height
end

Do you see that? It's our basic Rect(angle) class!  

So what?

? We finally created a working class! That's why it matters a lot! Now tell me if you do feel you need a subclass or parent class of it.

How should I know? You're the one that picked this specific topic!

Right... If you ever feel like that, probably you won't need either of them.
Yeah, you could later come up with other classes like other shapes, namely Circle, Triangle, and so on. Honestly you can stick to rectangles only for most of your gaming needs. At the end, you won't deal with any other geometrical shape unless you start using something like OpenGL and start depending on your graphics cards capabilities.  

So how do you know when to subclass some bunch of code? Here's when you should do that!

Code:

class Person
  def initialize(name)
    @name = name
    @age = 0
    @ssid = "0"
    @job = ""
    @skin_color = Color.new(0,0,0)
    @eye_color = Color.new(0,0,0)
    @hair_color = Color.new(0,0,0)
    @hobbies = []
    @relatives = []
    @phone_number = ""
  end
  attr_accessor :name, :age, :ssid, :job, :skin_color, :eye_color, :hair_color, :phone_number
  attr_reader :hobbies, :relatives
end

Do you know every single person share stuff in common?

I guess so...  

Well, that could later become our first parent class!

How so!?  

That's easy to explain! We know many people share traits like name, age, skin, eyes, hair, and so on. With this we can already create an object to represent a person like a student or coworker or site administrator or just some dreamer that complains about heat and many more!

So what's next?  

Coming up next would be our first child class! Let's define one right away!

Code:

class Gamer < Person
  def initialize(name)
    super
    @played_games = []
    @favorite_games = []
    @despised_games = []
    @hours_spent_gaming = 0
  end
  attr_reader :played_games, :favorite_games, :despised_games
  attr_accessor :hours_spent_gaming
end

Wow! You defined a gamer as inferior, less valuable than an average person!

Yeah, I did! But don't let that offend you in any way possible. I did that only for scripting purposes. For languages like Ruby anything that's related somehow to another basic class is "inferior" for a different reason. Actually it means it descends from a basic template called Person. Since a person isn't always a gamer, it's better to place Person first and Gamer as is direct subordinate. Nope, it's not his or her employee or servant, it's just a class that will call a Person's methods and add new ones that won't describe other persons but just gamers. I think it might be easy to understand if I show you another example now...

Go ahead!  

OK, this time we'll talk about lawyers!

Code:

class Lawyer < Person
  def initialize(name)
    super(name)
    @degree = ""
    @got_license = true
    @location = ""
    @workdays = []
    @customers = []
    @work_phone_number = ""
  end
  attr_accessor :degree, :got_license, :work_phone_number
  attr_reader :workdays, :customers
end

As you can see a lawyer, even if nobody likes them except for their own families also share common traits but got others as well. If we didn't have a Person as parent class, we would keep repeating code over and over again.

So you're teaching us how to become lazy as scripters!

You make it sound as a bad thing...

But it is bad indeed!

Nope, it isn't. At least not in this case. Ruby's and any other OOP's goal is to let you reuse code by subclassing stuff as much as needed. This way you won't need to copy thousands of lines of code every single time you wanna add new features or change them. Plus, why on earth would a busy Lawyer care about videogames? He needs to prepare for his next trial after all. He'd probably hate you for thinking all lawyers and even judges are like those found in Ace Attorney games.

Hey! I liked those games! They were quite realistic!

O_o? Are they!? Anyway, I've proven that we might need a basic parent class in case we might later define several descendants that will need to call stuff defined in the parent class. This pattern will save us from adding many checks in our code just to define when a person should turn on a TV set or open a briefcase or yell Objection! You wouldn't do that if you were just sitting on a seat like many other passengers while traveling on a bus or train or metro, would you!?

Now we're gonna discuss what's super!

 Batman is super indeed!  Many would say Superman is, but he's just a guy on steroids!

? Now we got somebody full of fleas that can't waste a chance to show off how he wasted his time reading comics.  

Actually for Ruby none of them would be super.

Say what!?

Yeah, none of them are, I do agree with Ruby on this. The main idea behind it would be that both of them would be living beings so none of them could be called super or need to call super, the Ruby method. For Ruby super means "Hey! Go call my parent and see if he needs to get some new name!" Actually Gamer and Lawyer did yell at Ruby they were passing a name to Person. They both did the exact same thing but one of them was lazy as to explicitly pass it and let Person assume he would know what they were handing out to him. Or were they irresponsible enough as to let others blame their parent instead?  

Code:

class Siletrea < WannabeDragonfly
  def initialize(name)
    @name = name
    @claws = []
    @age = 0
    @favorite_habitat = ""
  end
  attr_accessor :name, :age, :favorite_habitat
  attr_reader :claws
end

Wait a second! Why didn't you define Siletrea as another Person here?

? Is it my fault she believes she's a dragonfly? Plus she got claws, and believes she can fly and attack poor people like me. At the end she will fail to achieve her goal because she's a person and so our code will fail as well. You see, we never defined a WannabeDragonfly class before we defined her.

By the way, just in case you include arrays or hashes in your classes, you'd usually need getters only. Most of the time you'd just change their contents, not the entire array or hash. Thus there's no need to define something you don't need. That will keep your code clean and won't ask for extra resources that are gonna get wasted anyway.  

How large can a class ever be?

Err, again, that depends on your project and coding style. Usually you should only include what's enough to keep it running. Any extras should belong to specialized classes like subclasses alias child classes. There's no specific maximum size, but people say a large script takes longer to load than several short ones and the latter can let you find bugs in no time while the former might make it excessively complex for they might affect many lines of code at a single time. The only way you can be certain if it's a good or bad idea might be to load a project and its backup and see if any of those gets affected by how large the scripts currently are. Still, for a few scripts that won't ever matter. For hundreds of them I can't tell for sure it they will play along as a single, unified team. Even so new versions of Ruby might make it a bit harder to notice. Besides, non graphical scripts won't consume as many resources as those manipulating shapes or changing colors on the fly and so on.  

Warning!

Don't abuse of loops or you'll get stuck in no time!

Happy Stack Overflow!