Based on a question on Quora: http://www.quora.com/When-naming-classes-should-class-names-end-in-Manager "Does having class names as '...Manager' indicate poor design and mean the finer grained functionality of each component has not been well thought out?"

employee_example.rb

#Using the code below as an example
 
class Employees
  include Enumerable
  attr_reader :employees
 
  def employees
    @employees ||= []
  end
 
  def each(&block)
    employees.each &block
  end
 
  def <<(employee)
    employees << employee
  end
end
 
class Employee  
  attr_accessor :name, :email
  def initialize(args = {})
    args.each { |k,v| instance_variable_set("@#{k}",v) }
  end
end
 
class EmployeeFactory
  def self.create(args = {}, employee = Employee)
    employee.new(args)
  end
end
 
employees = Employees.new
employees << EmployeeFactory.create({ name: 'Larry Doe', email: 'ldoe@example.com' })
employees << EmployeeFactory.create({ name: 'Curly Doe', email: 'cdoe@example.com' })
employees << EmployeeFactory.create({ name: 'Moe Doe', email: 'mdoe@example.com' })
 
# One could argue that "EmployeeManager" could be the class that 
# maintains  "Employees" and the creation of "Employee" through the 
# "EmployeeFactory".  It really just depends on what your app is doing.  
 
# Example EmployeeManager
 
class EmployeeManager
 
  attr_accessor :employees, :employee
 
  def employees
    @employees ||= Employees.new
  end
 
  def employee
    @employee ||= Employee
  end
 
  def parse_employees(data = [])
    data.each { |h| add_new_employee(h) }
  end
 
  def add_new_employee(employee_info = {})
    employees << EmployeeFactory.create(employee_info)
  end
 
end
 
employee_data = [
  { name: 'Larry Doe', email: 'ldoe@example.com' },
  { name: 'Curly Doe', email: 'cdoe@example.com' },
  { name: 'Moe Doe'  , email: 'mdoe@example.com' }]
 
employee_manager = EmployeeManager.new
employee_manager.parse_employees employee_data
employee_manager.employees.each { |em| puts em.name }