Refactoring - Null Object: Part Two

This topic is for the [Null Object - Part Two] exercise in the [Refactoring] trail. Post any questions, corrections, or pointers you have to share with other Upcase subscribers.
[Null Object - Part Two]: https://exercises.upcase.com/exercises/null-object-part-two
[Refactoring]: Refactoring Code | Code Refactoring Online Tutorial by thoughtbot

When I initially ran rake I was receiving this error:

/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/activesupport-4.0.2/lib/active_support/values/time_zone.rb:282: warning: circular argument reference - now
.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rspec-core-3.3.1/lib/rspec/core/configuration.rb:644:in `block in expect_with': uninitialized constant RSpec::Expectations::MultipleExpectationsNotMetError (NameError)

To fix this I updated RSpec by running $ bundle update rspec

I then was getting two initial failing specs. To fix this:

  • In spec/user_spec.rb I changed true to truthy and false to falsey as follows:
    • expect(user.has_mentoring?).to be_truthy
  • expect(user.has_mentoring?).to be_falsey

After that all tests were green.

2 Likes

Hey harry!

I’ve been wondering how to technically solve the problem of creating new Null object instances within the following code setting:

def subscription
  @subscription || NoPlan.new
end

What is best practice to prevent creating a new NoPlan-instance everytime querying subscription?

The point is to return an instance that conforms to @subscription’s api so that the consumer doesn’t need to know they belong to different classes. so I’d say you don’t need to worry about returning NoPlan instances everytime in that particular snippet.

Sure, I was only wondering about memory-consumption. Do I have to be careful in a real-world setting, like a heavy-traffic-web-App with lots of requests spawning new null object instances or is that - in practice - a minor problem compared to other rails-memory-issues?

I don’t think it’s a problem at all. In such scenario, you will have other types of problems such as slow response times and issues on other parts of your stack such as databases (your sql database, redis, etc.)

If you think about it, an object oriented language it’s all about objects, so you shouldn’t need to worry about it.