As a Ruby programmer, you almost certainly make use of inheritance-based object modeling on a daily basis. In fact, extending base classes and mixing modules into your objects may be so common for you that you rarely need to think about the mechanics involved in doing so. If you are like most Ruby programmers, your readiness to apply this complex design paradigm throughout your projects is both a blessing and a curse.
On the one hand, your ability to make good use of inheritance-based modeling without thinking about its complexity is a sign that it works well as an abstraction. But on the other hand, having this familiar tool constantly within reach makes it harder to recognize alternative approaches that may lead to greater simplicity in certain contexts. Because no one tool is a golden hammer, it is a good idea to understand the limitations of your preferred modeling techniques as well as their virtues.
In this article, I will guide you through three properties of inheritance-based modeling that can lead to design complications unless they are given careful consideration. These are meant to be starting points for conversation more-so than tutorials on what to do and what not to do, so please attempt some of the homework exercises I’ve included at the bottom of the article!
PROBLEM 1: There is no encapsulation along ancestry chains
Inheritance-based modeling is most commonly used for behavior sharing, but what it actually provides is implementation sharing. Among other things, this means that no matter how many ancestors an object has, all of its methods and state end up getting defined in a single namespace. If you aren’t careful, this lack of encapsulation between objects in an inheritance relationship can easily bite you.
To test your understanding of this problem, see if you can spot the bug in the following example:
require "prawn" class StyledDocument < Prawn::Document def style(params) @font_name = params[:font] @font_size = params[:size] end def styled_text(content) font(@font_name) do text(content, :size => @font_size) end end end StyledDocument.generate("example.pdf") do text "This is the default font size and face" style(:font => "Courier", :size => 20) styled_text "This line should be in size 20 Courier" text "This line should be in the default font size and face" end
This example runs without raising any sort of explicit error, but produces the following incorrect output:
There aren’t a whole lot of things that can go wrong in this example,
and so you have probably figured out the source of the problem by now:
Prawn::Document each define
they each use it for a completely different purpose. As a result, calling
StyledDocument#style triggers a side effect that leads to this
To verify that a naming collision to blame for this problem, you can
try renaming the
@font_size variable in
something else, such as
@styled_font_size. Making that tiny
change will cause the example to produce the correct output,
as shown below:
However, this is only a superficial fix, and does not address the root problem.
The real issue is that without true subobjects with isolated state, the chance
of clashing with a variable used by an ancestor increases as your
ancestry chain grows. If you look at the mixins that
depends on, you’ll find examples of a
scary lack of encapsulation
that will make you wonder how things don’t break more often.
To make matters worse, the lack of encapsulation between objects in an inheritance relationship also means that methods can clash in the same way that variables can. A lack of true private methods in Ruby complicates the problem even further, because there simply isn’t a way to write a method in a parent object that a child object can’t clash with or override. One of the homework questions for this article addresses this issue, but is worth thinking about for a moment before you read on.
PROBLEM 2: Interfaces tend to grow rapidly under inheritance
I am going to attempt a proof without words for this particular problem, and leave it up to you to figure out why this can be a source of maintenance headaches, but please share your thoughts in the comments:
>> (ActiveRecord::Base.instance_methods | ActiveRecord::Base.private_instance_methods) => [:logger, :configurations, :default_timezone, :schema_format, :timestamped_migrations, :init_with, :initialize_dup, :encode_with, :==, :eql?, :hash, :freeze, :frozen?, :<=>, :readonly?, :readonly!, :inspect, :to_yaml, :yaml_initialize, :_attr_readonly, :_attr_readonly?, :primary_key_prefix_type, :table_name_prefix, :table_name_prefix?, :table_name_suffix, :table_name_suffix?, :pluralize_table_names, :pluralize_table_names?, :store_full_sti_class, :store_full_sti_class?, :store_full_sti_class=, :default_scopes, :default_scopes?, :_accessible_attributes, :_accessible_attributes?, :_accessible_attributes=, :_protected_attributes, :_protected_attributes?, :_protected_attributes=, :_active_authorizer, :_active_authorizer?, :_active_authorizer=, :_mass_assignment_sanitizer, :_mass_assignment_sanitizer?, :_mass_assignment_sanitizer=, :validation_context, :validation_context=, :_validate_callbacks, :_validate_callbacks?, :_validate_callbacks=, :_validators, :_validators?, :_validators=, :lock_optimistically, :attribute_method_matchers, :attribute_method_matchers?, :attribute_types_cached_by_default, :time_zone_aware_attributes, :skip_time_zone_conversion_for_attributes, :skip_time_zone_conversion_for_attributes?, :partial_updates, :partial_updates?, :partial_updates=, :serialized_attributes, :serialized_attributes?, :serialized_attributes=, :, :=, :record_timestamps, :record_timestamps?, :record_timestamps=, :_validation_callbacks, :_validation_callbacks?, :_validation_callbacks=, :_initialize_callbacks, :_initialize_callbacks?, :_initialize_callbacks=, :_find_callbacks, :_find_callbacks?, :_find_callbacks=, :_touch_callbacks, :_touch_callbacks?, :_touch_callbacks=, :_save_callbacks, :_save_callbacks?, :_save_callbacks=, :_create_callbacks, :_create_callbacks?, :_create_callbacks=, :_update_callbacks, :_update_callbacks?, :_update_callbacks=, :_destroy_callbacks, :_destroy_callbacks?, :_destroy_callbacks=, :auto_explain_threshold_in_seconds, :auto_explain_threshold_in_seconds?, :nested_attributes_options, :nested_attributes_options?, :include_root_in_json, :include_root_in_json?, :include_root_in_json=, :reflections, :reflections?, :reflections=, :_commit_callbacks, :_commit_callbacks?, :_commit_callbacks=, :_rollback_callbacks, :_rollback_callbacks?, :_rollback_callbacks=, :connection_handler, :connection_handler?, :connection, :clear_aggregation_cache, :transaction, :destroy, :save, :save!, :rollback_active_record_state!, :committed!, :rolledback!, :add_to_transaction, :with_transaction_returning_status, :remember_transaction_record_state, :clear_transaction_record_state, :restore_transaction_record_state, :transaction_record_state, :transaction_include_action?, :serializable_hash, :to_xml, :from_xml, :as_json, :from_json, :read_attribute_for_serialization, :reload, :mark_for_destruction, :marked_for_destruction?, :changed_for_autosave?, :_destroy, :reinit_with, :clear_association_cache, :association_cache, :association, :run_validations!, :touch, :_attribute, :type_cast_attribute_for_write, :read_attribute_before_type_cast, :changed?, :changed, :changes, :previous_changes, :changed_attributes, :to_key, :id, :id=, :id?, :query_attribute, :attributes_before_type_cast, :raw_write_attribute, :read_attribute, :method_missing, :attribute_missing, :respond_to?, :has_attribute?, :attribute_names, :attributes, :attribute_for_inspect, :attribute_present?, :column_for_attribute, :clone_attributes, :clone_attribute_value, :arel_attributes_values, :attribute_method?, :respond_to_without_attributes?, :locking_enabled?, :lock!, :with_lock, :valid?, :perform_validations, :validates_acceptance_of, :validates_confirmation_of, :validates_exclusion_of, :validates_format_of, :validates_inclusion_of, :validates_length_of, :validates_size_of, :validates_numericality_of, :validates_presence_of, :errors, :invalid?, :read_attribute_for_validation, :validates_with, :run_callbacks, :to_model, :to_param, :to_partial_path, :attributes=, :assign_attributes, :mass_assignment_options, :mass_assignment_role, :sanitize_for_mass_assignment, :mass_assignment_authorizer, :cache_key, :quoted_id, :populate_with_current_scope_attributes, :new_record?, :destroyed?, :persisted?, :delete, :becomes, :update_attribute, :update_column, :update_attributes, :update_attributes!, :increment, :increment!, :decrement, :decrement!, :toggle, :toggle!, :psych_to_yaml, :to_yaml_properties, :in?, :blank?, :present?, :presence, :acts_like?, :try, :duplicable?, :to_json, :instance_values, :instance_variable_names, :require_or_load, :require_dependency, :require_association, :load_dependency, :load, :require, :unloadable, :nil?, :===, :=~, :!~, :class, :singleton_class, :clone, :dup, :initialize_clone, :taint, :tainted?, :untaint, :untrust, :untrusted?, :trust, :to_s, :methods, :singleton_methods, :protected_methods, :private_methods, :public_methods, :instance_variables, :instance_variable_get, :instance_variable_set, :instance_variable_defined?, :instance_of?, :kind_of?, :is_a?, :tap, :send, :public_send, :respond_to_missing?, :extend, :display, :method, :public_method, :define_singleton_method, :object_id, :to_enum, :enum_for, :psych_y, :class_eval, :silence_warnings, :enable_warnings, :with_warnings, :silence_stderr, :silence_stream, :suppress, :capture, :silence, :quietly, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__, :__id__, :initialize, :to_ary, :_run_validate_callbacks, :_run_validation_callbacks, :_run_initialize_callbacks, :_run_find_callbacks, :_run_touch_callbacks, :_run_save_callbacks, :_run_create_callbacks, :_run_update_callbacks, :_run_destroy_callbacks, :_run_commit_callbacks, :_run_rollback_callbacks, :serializable_add_includes, :associated_records_to_validate_or_save, :nested_records_changed_for_autosave?, :validate_single_association, :validate_collection_association, :association_valid?, :before_save_collection_association, :save_collection_association, :save_has_one_association, :save_belongs_to_association, :assign_nested_attributes_for_one_to_one_association, :assign_nested_attributes_for_collection_association, :assign_to_or_mark_for_destruction, :has_destroy_flag?, :reject_new_record?, :call_reject_if, :raise_nested_attributes_record_not_found, :unassignable_keys, :association_instance_get, :association_instance_set, :create_or_update, :create, :update, :notify_observers, :should_record_timestamps?, :timestamp_attributes_for_create_in_model, :timestamp_attributes_for_update_in_model, :all_timestamp_attributes_in_model, :timestamp_attributes_for_update, :timestamp_attributes_for_create, :all_timestamp_attributes, :current_time_from_proper_timezone, :clear_timestamp_attributes, :write_attribute, :field_changed?, :clone_with_time_zone_conversion_attribute?, :attribute_changed?, :attribute_change, :attribute_was, :attribute_will_change!, :reset_attribute!, :attribute?, :attribute_before_type_cast, :attribute=, :convert_number_column_value, :attribute, :match_attribute_method?, :missing_attribute, :increment_lock, :_merge_attributes, :halted_callback_hook, :assign_multiparameter_attributes, :instantiate_time_object, :execute_callstack_for_multiparameter_attributes, :read_value_from_parameter, :read_time_parameter_value, :read_date_parameter_value, :read_other_parameter_value, :extract_max_param_for_multiparameter_attributes, :extract_callstack_for_multiparameter_attributes, :type_cast_attribute_value, :find_parameter_position, :quote_value, :ensure_proper_type, :destroy_associations, :default_src_encoding, :irb_binding, :Digest, :initialize_copy, :remove_instance_variable, :sprintf, :format, :Integer, :Float, :String, :Array, :warn, :raise, :fail, :global_variables, :__method__, :__callee__, :eval, :local_variables, :iterator?, :block_given?, :catch, :throw, :loop, :caller, :trace_var, :untrace_var, :at_exit, :syscall, :open, :printf, :print, :putc, :puts, :gets, :readline, :select, :readlines, :`, :p, :test, :srand, :rand, :trap, :exec, :fork, :exit!, :system, :spawn, :sleep, :exit, :abort, :require_relative, :autoload, :autoload?, :proc, :lambda, :binding, :set_trace_func, :Rational, :Complex, :gem, :gem_original_require, :BigDecimal, :y, :Pathname, :j, :jj, :JSON, :singleton_method_added, :singleton_method_removed, :singleton_method_undefined]
There is a specific issue I have with interface explosion, and it isn’t so much to do with code organization as it is with state management. Can you guess what my concern is?
PROBLEM 3: Balancing reuse and customization can be tricky
Some ancestors provide methods that are designed to be replaced by their descendants. When executed well, this pattern provides a convenient balance between code reuse and customization. However, because it is impossible to account for all possible customizations that descendants of a base object will want to make, this approach has its limitations.
This design problem is best explained by example, and you can find a great one in Ruby itself. Start by considering the following trivial code, paying particular attention to its output:
Under the hood,
person.to_s. What you see above is output from the default implementation
of each of those methods. Arguably,
provides useful debugging output, but
more of a template method that needs to be overridden in order to be useful. The
following code shows how easy to customize things by simply adding your own
On the surface, there is nothing wrong with this code: this is exactly what a
template-method based extension mechanism should look like. However, due to the
weird way that
Object#inspect works in Ruby 1.9, defining your own
implementation has some unpleasant side effects that are likely to surprise you:
p person #=~ Gregory Brown <[email protected]>
If you look at the definition of
you’ll find that this behavior is by design. In a nutshell, the method is set
up to provide its default output if
to_s has not been overridden, but simply
to_s if it has been. This is problematic, because
to_s is meant
to be used for humanized output such as what you saw in the previous
example, not debugging output.
The unfortunate consequence of this problem is that if you define
to_s in your
objects, you must also define a meaningful
inspect, and if you want to
reproduce the same behavior as
Object#inspect, you need to implement
it yourself. While this is mostly a problem of brittle code and it is not
specifically related to inheritance, the problem is compounded by
inheritance-based modeling. For example, suppose the
Person class was defined
as shown above, and you decided to subclass it:
class Employee < Person def initialize(name, email, role) super(name, email) @role = role end end
Person does define its own
Employee will inherit the
same problem. On the other hand, if
Person does implement
inspect, it needs
to take care to implement it in a way that’s suitably general to account for
what its descendants might find useful. This invites the same design challenges
that caused this problem in the first place, which means that
Employee may end
up cleaning up after its parent object in a similar way. Unfortunately,
brittleness tends to cascade downwards throughout ancestry chains.
This article is on the short-side, and it also leaves out a lot of the story from each of these points. I did this intentionally to encourage you to participate in an active discussion on this topic. To get the most out of this article, please complete at least one of the following homework exercises:
1) Show a realistic example of an accidental method naming collision, in a similar spirit to the state-based example shown in Problem #1. For bonus points, choose an example that involves private methods.
2) Post a comment in response to the “interface explosion” example shown in Problem #2. You can either try to guess what my main concern about it is, or share your own concerns. If instead you feel that there is nothing wrong with this kind of design, explain why you think that.
3) Come up with another downside of inheritance-based modeling, and provide an
example of it. If you have trouble coming up with your own, you may want to look
into issues that can arise from overriding methods, or perhaps explore what
happens when you mix traditional inheritance-based modeling with
4) Share an example of a library or project which is difficult to work with because of the way it uses inheritance-based modeling, or describe problems you’ve run into with your own projects due to inheritance.
5) Share the conventions and guidelines you follow to avoid the problems described in this article, as well as other problems you’ve encountered with inheritance-based modeling.
Looking forward to seeing your responses! Don’t worry about getting the right answers, discussion threads here on Practicing Ruby are about learning, not necessarily showing off what you already know.
Practicing Ruby is a Practicing Developer project.
All articles on this website are independently published, open source, and advertising-free.