Refactor configuration hashes to use value objects

[kanejamison]

Description

The configuration system currently stores post types and collections as plain hashes. While functional, this approach misses opportunities for encapsulation, type safety, and behavior encapsulation that value objects provide.

Current code

lib/bunko/configuration.rb:81-89:

post_type = {name: name_str, title: generated_title}

if block_given?
  customizer = PostTypeCustomizer.new(post_type)
  block.call(customizer)
end

@post_types << post_type

Problems this causes

1. No encapsulation - easy to access with wrong keys or typos
2. No type safety - can store any value in any key
3. Hard to add computed properties or methods
4. No validation after creation
5. Customizer objects exist but only expose setters, not behavior
6. Makes testing and mocking more difficult

Pros of refactoring

• Clear API with defined attributes
• Enables adding computed properties (e.g., url_path, route_name)
• Type safety and validation
• Better IDE/editor support (autocomplete, type hints)
• Easier to extend with new features
• More maintainable and testable

Cons of refactoring

• Adds slight complexity (new classes to maintain)
• Breaking change if anyone is accessing configuration internals directly
• Need to update all hash access to method calls

Recommended approach

Use Struct or simple value objects:

PostTypeConfig = Struct.new(:name, :title, :per_page, keyword_init: true) do
  def url_path
    name.tr("_", "-")
  end
  
  def to_h
    {name: name, title: title, per_page: per_page}
  end
end

CollectionConfig = Struct.new(:name, :title, :post_types, :scope, keyword_init: true) do
  def url_path
    name.tr("_", "-")
  end
end

This provides a clean API while maintaining backward compatibility via to_h if needed.

References

• lib/bunko/configuration.rb:81-89
• lib/bunko/configuration.rb:125-136 (collection hash creation)