Focus on good ol' OOP and specifically Tell-Don't-Ask?

[knewter]

The biggest thing I'd want to avoid with this (though there are a ton of benefits) is view-side - reaaaaally don't want the views to look like:

- if field.is_a?(SelectField)
  = f.select field.name, blah
- elsif DAMMIT I WANT TO DIE
- else PLEASE?

[gogogarrett]

+1

[johanb]

If it leads to better, easier to understand code 👍

[parndt]

If it leads to better, easier to understand code

I feel @knewter should weigh in on that.

[knewter]

So a fun example of benefits of proper OOP rather than gobs-and-gobs of if/else/case statements is here: https://github.com/knewter/probably_worth_watching/blob/master/lib/probably_worth_watching/gathers_video_metadata_analyzer.rb#L15

That is, in that example, each of the potential analyzers can himself describe which sorts of things he handles. To use them, or to slot new ones in, requires nothing but putting them in the object graph (in theory - in practice, I add them to an array as well because I didn't feel like doing it with introspection, but that's probably a bad idea).

I just think the up-front effort required to separate our concepts such that views can be written in something other than if/else soup ends up having a massive payoff, in every project in which I've done it. It also keeps code complexity down.

The 'downside' of doing this is that "you end up with a lot of classes." That's pretty much the only downside, as far as I know. But ideally you abstract the 'class explosion' behind some nice interfaces and you never have to keep them in your head.

That's the thought, at least. I just really want to see more ruby code being purty OO stuff, and the world's clamoring for good examples of solid OO in rails, so why not give it to them? :)

[robyurkowski]

The 'downside' of doing this is that "you end up with a lot of classes." That's pretty much the only downside, as far as I know. But ideally you abstract the 'class explosion' behind some nice interfaces and you never have to keep them in your head.

That's a downside?

Honestly, I'd much rather have numerous classes that are all documented and can be looked up in the APIdocs super fast, than a splorch of if/else paint in the view layer.

I'd also say that it's important to do this only once you reach a certain threshold:

1. You've now done this twice; or
2. The complexity is such that you're doing more than a single-layer of branching logic.

To show what I mean, I want to refer to @parndt's example in #7:

<% if something %>
  <% if something_else %>
    <%= "foo" %>
  <% else %>
    <%= "bar" %>
  <% end %>
<% else %>
  <%= "Nothing found in your search" %>
<% end %>

parndt was mentioning this to show how that makes him want to use haml. The truth of the matter is that haml doesn't make this any prettier; it just means you get to use the shift key a bit less (angle brackets and % signs are the devil). This is a partial, and if not a partial, then a class.

EDIT: by a partial, I mean the second if/else block inside the first one should be extracted into something like this:

<% if something %>
    <% render 'something_else_partial' %>
<% else %>
    <%= "Nothing found in your search" %>
<% end %>

[ugisozols]

Looking at the example @knewter provided I rememebr I did something very similar in Refinery CMS. Check out this PR - refinery/refinerycms#2031.

[parndt]

I'm so excited for this feature alone.