Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Objectify: A Better Way to Build Rails Applications

jamesgolick.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Objectify: A Better Way to Build Rails Applications

#41

Post by stiff »

jamesgolick wrote: post #37
stiff wrote: post #36

Earlier quoted context omitted.

You have to think a bit more about what OO really is about. How would properties of your solution differ if you instead of classes split all the code into many very small global methods? The essence of OO is objects freely passing messages between themselves, if you fix all the message routing and put it in a central place you are not doing OO anymore, you loose the most fundamental properties, for example: http://en…

> You have to think a bit more about what OO really is about. If you want to have a respectful debate, I'm completely game. If you'd prefer to continue with your incredibly condescending tone, then I'll bow out here.

Well, maybe I got carried away a bit with the tone in general in the last paragraphs of both comments, but I think I substantiated the particular sentence you cited quite a bit. On the other hand, I also took half an hour to clearly explain to you why this is somewhat misguided and tried hard to be polite, while someone below just said "this is fucking ridiculous". It's hard, at least for me, to give constructive criticism, without the other person being offeneded.

Re: Objectify: A Better Way to Build Rails Applications

#43

Post by jes5199 »

manuscreationis wrote: post #16

When I was first trying to learn about rails, I asked a friend who had been developing in it for a while about things like DI, and separation of concerns. He told me that those were things you used in Java and .Net because the languages just weren't as... I'm struggling to remember the exact term he used, but essentially "open" or "un-restricted". He echoed the phrase I've seen elsewhere "Ruby just doesn't need that"…

He probably used the word "expressive", which is how we used to excuse ruby's problems.

It's pretty clear, by now, that we (the ruby community) were wrong about how to maintain projects over time without getting mired in complexity.

Re: Objectify: A Better Way to Build Rails Applications

#44

Post by jes5199 »

brunoc wrote: post #5

I don't get why these models get bloated. If there's a language that makes it east break up classes into any number of components, surely that's Ruby! Mixins, open classes, modules, etc..

I find that ruby projects end up breaking things up into modules, but fail to gain much benefit from it, since there's a tendency for the logic from the different "modules" to be tightly coupled. It's actually really hard to refactor ruby, since because it's so dynamic and so much state is shared, it's very hard to make safe changes.

Re: Objectify: A Better Way to Build Rails Applications

#45

Post by drumdance »

"The more responsibilities an object has, the more complex its behaviour becomes, and is therefore more difficult to prove and reason about."

Emphasis mine. I don't think this has to be true. Yes, models get fatter, but the responsibilities will have to be implemented somewhere and to me it's simpler and easier to debug when it's as close to the domain model as possible instead of in some abstract/generic model.

Of course, if you have policies and services that apply across domains, then by all means break them out and recompose as necessary in the the models

Re: Objectify: A Better Way to Build Rails Applications

#46

Post by perlpimp »

Not quote Donald K. but I've seen my share of optimizing rails apps that points to the fact that each class added is extra 2-4 megs of RAM. This sort of discouraging rule, looking ahead writing well tested app that does follow SRP and other nifty "literate" practices might cost you big time, tell me if I am wrong.

Re: Objectify: A Better Way to Build Rails Applications

#47

Post by nicholasjhenry »

judofyr wrote: post #22

Someone has to say it: Damn, this looks fucking ridiculous! First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them mo…

When you start a comment off with a sentence like that, you lose all credibility.

Re: Objectify: A Better Way to Build Rails Applications

#48

Post by primatology »

nicholasjhenry wrote: post #47
judofyr wrote: post #22

Someone has to say it: Damn, this looks fucking ridiculous! First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them mo…

When you start a comment off with a sentence like that, you lose all credibility.

I don't necessarily think so. He draws you in with said outrageous remark and proceeds to raise some good points.

Re: Objectify: A Better Way to Build Rails Applications

#49

Post by stiff »

iamgilesbowkett wrote: post #33

I have a prejudicial assumption that if you don't know the problem Objectify solves, you haven't worked with a Rails app which has A) a large code base B) a large, active user base and C) a bunch of different features. The vast majority of people who scale Rails sites (as far as I can tell) do so by breaking their apps into services. ActiveRecord god-objects do not make that step in an app's life cycle easy, and sepa…

I worked in Rails for the last 6 years professionally, and for the last 4 years on a single application. There are lots of ways to tackle this problem, but it really depends what precisely you have inside those models and there are certainly no universal silver bullets. Lots of people who complain about this underuse Rails features, external plugins etc. I think two good ways to deal with the problem are:

- Splitting out logical pieces of behaviour into separate modules, especially the ones less central to the core responsibilities of the class. If you look at Rails itself (it's great Ruby code, I highly recommend really reading it), this is the way it is structured, ActiveRecord::Base provides tons of functionality as a single class, yet it still is very neatly laid out into many well-separated modules. See e. g.:

https://gist.github.com/1014971

http://api.rubyonrails.org/classes/ActiveSupport/Concern.htm...

https://github.com/jakehow/concerned_with

http://blog.waxman.me/extending-your-models-in-rails-3

Deciding what things would fit well into external modules and what modules to create is a new skill to be learned, but I think it can work well once you do learn it.

- Things that aren't part of business logic but just handle some more technical matters should be extracted into plugins and not be directly part of the models (for example: special kinds of validations).

- There is the whole world of OO techniques and patterns that can be applied here just like anywhere else. For example you can extract complicated algorithms into separate classes or use value objects:

http://api.rubyonrails.org/classes/ActiveRecord/Aggregations...

Re: Objectify: A Better Way to Build Rails Applications

#50

Post by nicholasjhenry »

primatology wrote: post #48
nicholasjhenry wrote: post #47

Earlier quoted context omitted.

When you start a comment off with a sentence like that, you lose all credibility.

I don't necessarily think so. He draws you in with said outrageous remark and proceeds to raise some good points.

It doesn't really invite discussion. If you were the original author of the blog post would you engage with the author of the comment?
Post reply on HN