CODEWITHSUNDEEP
oopdesign-patterns
Snowcrash
Snowcrash

Reputation: 86297

Design patterns on initializing an object?

What's the recommended way to handle an object that may not be fully initialized?

e.g. taking the following code (off the top of my head in ruby):

class News
  attr_accessor :number

  def initialize(site)
    @site = site
  end

  def setup(number)
    @number = number
  end

  def list
    puts news_items(@site, @number)
  end
end

Clearly if I do something like:

news = News.new("siteA")
news.list

I'm going to run into problems. I'd need to do news.setup(3) before news.list.

But, are there any design patterns around this that I should be aware of?

Should I be creating default values? Or using fixed numbers of arguments to ensure objects are correctly initialized?

Or am I simply worrying too much about the small stuff here.

Upvotes: 3

Views: 342

Answers (1)

Sam Holder
Sam Holder

Reputation: 32946

Should I be creating default values?

Does it make sense to set a default? If so this is a perfectly valid approach IMHO

Or using fixed numbers of arguments to ensure objects are correctly initialized?

You should ensure that your objects cannot be constructed in an invalid state, this will make your's and other users of your code much simpler.

in your example not initializing number in some way is a problem, and this method is an example of temporal coupling. You should avoid this, and the two ways you suggested are ways to do this. Alternatively you can have another object or static method responsible for building your object in a valid state instead

If you do have an object which in not fully initialised then any invalid methods should produce appropriate and descriptive exceptions which let the users know that they are using the code incorrectly, and gives examples of the correct usage patterns.

In c# InvalidStateException is usually appropriate and similar exceptions exist in Java. Ruby is beyond my pay grade unfortunately :)

Upvotes: 1

Related Questions