-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Focus on good ol' OOP and specifically Tell-Don't-Ask? #9
Comments
+1 |
If it leads to better, easier to understand code 👍 |
I feel @knewter should weigh in on that. |
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? :) |
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:
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 %> |
Looking at the example @knewter provided I rememebr I did something very similar in Refinery CMS. Check out this PR - refinery/refinerycms#2031. |
I'm so excited for this feature alone. |
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:
The text was updated successfully, but these errors were encountered: