I have had some of the most amazing revelations while reading this book! I now understand why my code gets so entangled even though I do create objects and try to respect boundaries I constantly fight code changes that ripple throughout the application. I have been refactoring like crazy!
Chapter 7
"The previous chapter ended on a high note, with code that looked so promising you may be wondering where it's been all your life." YES!!!
Chapter 2
"The future is uncertain and you will never know less than you know right now." I think you need to emphasize this more!
Who creates the objects?
While I understand the loose coupling to create resusable objects, at some point, someone has to create the objects. Someone has to call Trip.new and Bicycle.new. In a Rails project, that would probably be in a Controller, but in a non-Rails Ruby program, it seems like you could end up with one main program that knows about and creates all the objects.
For example, Chapter 8, pages 180-182: where do the xxx_config definitions reside and where to the xxx_bike creations reside?
I would like more clarification about class name dependencies.
I find myself struggling to reduce the class name dependencies. Lots of my classes want to create an object of another type, and I don't always know whether that's appropriate. When I do try to extract that dependency, I end up with a different class creating that object.
Furthermore, the original class invariably ends up with a parameter or variable with a very similar name to the class that I (now) do not create. E.g. instead of my_x = X.new, I now have my_x = args[:some_x]
Implementing duck typing vs composition is sometimes confusing.
A Bicycle is Schedulable, but you can also say a Bicycle has-a Schedule. I sometimes get confused between the interface and the object.
For example, let's say I have a module Loggable which implements some debugging log functions. I can say that my Bicycle is Loggable, but that creates an external interface where someone could call:
Bicycle.new.log_debug('Created bike.')That's not really what I want. What I want is for methods inside my Bicycle to be able to write to the log, such as:
def initialize(args)
log_debug('Created bike.') # I "inherit" private logging functions
...
end or
def initialize(args)
logger.debug('Created bike.') # I magically have-a logger object
...
end In the second option, I would like to get a logger instance without having to instantiate it myself using MyLogger.new.
What are the guidelines for using OpenStruct factories?
Would you only use them for specialized objects of a generic concept (Parts)?