Hacker News new | past | comments | ask | show | jobs | submit login

We tried using DHH's concerns in place for interactors, but ditched them for PORO/service objects because they can be tested outside Rails.



Yeah - I feel like concerns are a bit of an anti-pattern, especially as they're normally used in Rails.

You've got a God class that exposes 500+ public methods, so you split it into concerns. But now you've still got a God class with 500 methods that's split across 10 files. Good luck understanding that.

Concerns are useful when they're genuinely sharing functionality between classes - not just for splitting up "Big Bags O' Methods".


> Concerns are useful when they're genuinely sharing functionality between classes - not just for splitting up "Big Bags O' Methods".

Hmmm. I'd say it depends.

Of course having concerns (a fancy word for modules IMHO) shared between classes is great. But i've also found cases where separating a god class' behaviour into different concerns helped a lot. The important thing in those cases was recognizing and avoiding dependencies between different concerns, so instead of ending up with a god class split across many files of inter-dependant code (i.e. worse than before), you can end up with a "god" class split into its minimal "core" part and a couple of concerns that only depend on that core part but not between each other. Yes, you could still call that a god class, as it will have a very fat public API, but at least you can reason about what it does in terms of different concerns, so you gain something :)


Concerns are useful when they're genuinely sharing functionality between classes

I've found them genuinely useful for that - there is a lot of code for things like urls, publish status, ratings, roles, permissions etc that can be shared between models if they have similar functionality.

They're just a recognition that composition via modules is often better than inheritance.


I don't like Concerns because usually they are just hiding behaviors in another file (I do like routing concerns though!). You can test Concerns outside of Rails though, all you need is ActiveSupport which actually loads quite fast.

require 'active_support/concern'

require 'my_cool_concern'

class DummyClass

  include MyCoolConcern
end


This assumes that MyCoolConcern doesn't depend on too many things in your main model class or in (god forbid) other concerns that you've included in that model.

Or, perhaps, to turn this argument around, it's better to say it this way: A Concern is poorly-constructed if it cannot be tested in isolation, so therefore something like MyCoolConcern should be written with its testability (inside of DummyClass) in mind.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: