Ruby Scripting

[kyonides]

To Encapsulate? Or Not to Encapsulate?

That is the... Controversy!

On another board I wound up talking about breaking encapsulation.

What is encapsulation?

Is it a bad thing at all?

The term itself is defined as:

Encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

A language mechanism for restricting direct access to some of the object’s components.

A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

That is limiting how you call and manipulate a given portion of code belonging to the object. Keep in mind that an object can be either a class or a module in  Ruby. Even numbers are objects because they do own several methods.

The second part handles the way you implement your internal and external calls inside blocks called methods in Ruby and functions in C, C++ and Javascript. This is some sort of task management. A single method is NOT supposed to take care of EVERYTHING.

A bad example that is linked to the lack of modularity is any main method in scene scripts found in RMXP. main contains almost everything. (The usual exception would be its update method.) That changed in VX and VX ACE because they do feature many helper methods like pre_start and start or terminate there. Now every method has a task or a group of related tasks to perform inside every method.

How do we know we are breaking the encapsulation?

Have you asked a scripter to give you at least a hint on how to access any of the current scene's methods from the Game_Party or the Spriteset_Map or vice versa?

Guess what? You broke it!   

You are only supposed to access the methods already provided by the script and that's it!

 Oh yes, I know that it would make custom patches very difficult to be crafted under certain circumstances. Even so, you could accomplish the same goal in a totally indirect way instead.

And it is totally true that we got the attr_reader and attr_writer or attr_accessor methods to quickly make its variables accessible for free. But there's a catch!

What happens if you call the variable directly?

In order to make a point here, I will need to come up with some mockup code to better illustrate it.

Code:

class Game_System
  alias :gm_sys_init :initialize
  def initialize
    gm_sys_init
    @traps = []
  end
  attr_reader :traps
end

There I created a new traps method belonging to the Game_System class that is accessible via the $game_system global variable.

Am I breaking the encapsulation principle here?
Apparently not... but I could be in no time.

 How could you do it?

Well, it could be as EASY as making the following call.

Code:

$game_system.traps[10] = BearTrap.new

There I have already altered the actual contents of the traps Array without caring about checks and controls.

Such cases demand from us the creation of custom methods to ensure we won't be leaving blank spaces or any foreign object that should not be found there like a number or a boolean.

A good but quite limiting example of this could be the $game_party.add_actor method that will limit the number of heroes that can join our party in RMXP or RMVX.

Yes, that means you got to create more and more wrapper methods to keep access to $game_system or $game_party methods safe.

A scripter's life is hard, guys!