bjhess wrote:
As I get deeper into my app, I find myself writing a lot of "if"
statements.
Open an old, boring book from ~10 years ago called /Design Patterns/.
Write tests for every single effect of your if statements.
If you duplicate any if statement, refactor your code to create objects
with polymorphic methods. Run all the tests between each small code
change. Share each new object between the places where the if
statements duplicated. This is the heart of OO.
If a user is logged in, I want their profile page to say "Your last 10
comments" versus "username's last 10 comments".
Start by "hiding" those if statements. Put them inside method calls
that return either Your or 'usernames's.
Then move the if statement itself out to a function that decides - once
and only once - which kind of relationship your application has with
the user. if current_user == @user then FamiliarInterface.new else
SociableInterface.new end. Pass that object around, and put inside it
every if statement that dealt with familiarity with the user.
You may eventually arrive at the Decorator Pattern.
BTW one major problem with Ruby is you won't learn many of the
classical design patterns, such as Prototype or Adapter. Ruby makes
them way too easy. /Design Patterns/ was written with C++ and Smalltalk
examples, so you may need to switch to a harder language to learn them.
A partial is used to display a post. If a post is displayed on a list
screen, link the post title to a post_detail page. If a post is
displayed on a post_detail page, don't link the post title to anything.
In this case, pass a :local into the partial that writes the link. The
caller knows which object to pass in. The caller could even decide to
pass in a block closure. Or it could chose from predefined and reusable
objects.
Look up "Construction Encapsulation" - another critical technique that
Ruby makes too easy.
I just need a nudge in the right direction. Should I simply be moving
all this "if" code to helper classes? Or am I missing a pretty
standard OO or RoR concept here that would make my code much more solid
and less, well, "iffy".
Yes. The heart of OO, and the reason OO is a powerful design technique,
is that each time you replace a conditional with polymorphism, you have
a new object that can now replace other conditionals
The great thing about Rails is it already did a lot of this OO
polymorphism for you. You no longer have to claw your way through a
maze of if Database if Controller if View nonsense. These kids these
days probably don't remember classical Perl CGI website development!
Back in my day, we had to bless our hashes!!
The power of Rails has lead you to create a complex beast of your own,
hosted within it. So you now need to apply your own abstractions, to
keep your own layer of the design clean and flexible.
If you don't clean up your design (and if you don't write unit tests)
then each time you add a new feature, you must balance its new if
statements against all your old ones, including ones you might forget
about. This decay will cause bugs, and the design quality will go down.
Then, fixing bugs will cause more bugs.
So the time to learn OO and apply it here is as early as possible,
before the design decays!
