Public and Private Interfaces in ruby

 

Your latest client is a bank, and they’ve tasked you with requiring customers to enter their password in order to make withdrawals.

Currently, this is what they’ve got:

class Customer
  attr_reader :funds

  def initialize(funds, password)
    @funds = funds
    @password = password
  end

  def remove_funds(amount)
    @funds -= amount
  end
end

Let’s break that apart. You can paste that whole class into irb to follow along.

When a customer is initialized, it receives a specified amount of funds and a password is set.

diego = Customer.new(500, "udacious")
# => #<Customer:0x007fcdb48ca5a8 @funds=500 @password="udacious">

Thanks to the attr_reader, you can see the value of his current funds.

diego.funds
# => 500

And the remove_funds method allows funds to be removed from the customer’s account.

Checking on the funds again confirms this.

diego.remove_funds(50)
# => 450
diego.funds
# => 450

These methods, funds and remove_funds, are part of the Customer class’ API, or application programming interface.

An API is, according to Wikipedia, “a set of routines, protocols, and tools for building software applications”.

Well, that’s vague.

“API” is a popular term in recent years, but many people use it without quite understanding what it means. Think of methods like remove_funds as your way of interfacing with the Customer class. These methods are the keys to accessing information about a particular customer.

There isn’t currently a way to access the @password instance variable.

It could be said that the customer’s password can’t be accessed by the customer’s public API.

In this situation, that’s a good thing! You don’t want information like a password to be publicly available to other objects.

Let’s implement a method called withdraw_securely, which takes two arguments, amount andpassword.

If the password entered matches the customer’s password, go ahead and remove the funds. Otherwise, nothing happens.

class Customer
  attr_reader :funds

  def initialize(funds, password)
    @password = password
    @funds = funds
  end

  def remove_funds(amount)
    @funds -= amount
  end

  def withdraw_securely(amount, password)
    if password == @password
      remove_funds(amount)
    end
  end
end

Play around with this in irb to see it in action.

diego.withdraw_securely(50, "udacious")
# => 400
diego.withdraw_securely(100, "wrong password")
# => nil
diego.funds
# => 400

✨Hooray. Calling withdraw_securely using the correct password decreases the total funds by calling remove_funds,

while using the incorrect password does nothing.

There’s one issue here, can you spot it?

diego.remove_funds(75)
# => 325
diego.funds
# => 325

Malicious users can still withdraw funds directly using the remove_funds method! 😱

With this current setup, both remove_funds and withdraw_securely are part of a customer’s public API.

In reality, remove_funds needs to somehow be tucked away so that it isn’t accessible via the public API.

This can be done by making it a private method.

Private methods can be invoked only from within a class. If remove_funds were a private method,

that would mean it can only be accessed by another method, like withdraw_securely. To do this, you can use the private keyword.

class Customer
  attr_reader :funds

  public

  def initialize(funds, password)
    @password = password
    @funds = funds
  end

  def withdraw_securely(amount, password)
    if password == @password
      remove_funds(amount)
    end
  end

  private

  def remove_funds(amount)
    @funds -= amount
  end
end

Here, anything after the private keyword will be treated as a private method. Test it out in irb and see it in action!

diego.withdraw_securely(75, "udacious")
# => 250

Okay, withdraw_securely still works as expected...

diego.remove_funds(100)
NoMethodError: private method 'remove_funds' called for
#<Customer:0x007fcdb496ae40 @funds=400, @password="udacious">

But now remove_funds throws an error! A NoMethodError in particular. If you read through this error,

you’ll see that it does exactly what you intended: it will not let you call the private method,remove_funds.

Using private methods allows you to reuse logic in your code without having to worry about exposing it to other classes.

As a guiding principle, it’s not a bad idea to assume a method should be private until you’ve been given a good reason to make it a part of an object’s public API.

Going Public

Technically, there’s also a public keyword. It works just like the private keyword, and it’s used to indicate that methods should be publicly available.

The public and private keywords (there’s also protected, but we’ll get to that later) can only be used once inside each class, and methods are by default public.

class Customer
  attr_reader :funds

  public

  # public methods...

  private

  # private methods...
end

While this would technically work just fine, using the public keyword tends to be redundant. You’ll hardly ever see it in code anywhere.

A disclaimer about Private Methods

Guilty confession: just because a method is private doesn’t mean it can’t ever be called.

diego.send(:remove_funds, 65)
# => 185

There’s a little workaround using the send method, which sends the method of the name you specify (in this case, :remove_funds) to be called by the object.

What does this mean for you? Well, if security is actually a primary concern for you, creating a private method alone isn’t enough of a solution.

But the benefits of tucking away private methods remain. Indicating that a method is private lets other developers know that a method isn’t intended to be part of an object’s public API, and discourages them from using it.