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

31–40 of 72 posts

Re: Objectify: A Better Way to Build Rails Applications

#31

Post by jamesgolick »

manuscreationis wrote: post #23
jamesgolick wrote: post #17

Earlier quoted context omitted.

> It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start to matter. The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a har…

>The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm. Sure. I wasn't saying otherwise. What I meant was, in a general sense (prior to really seeing the benefits first hand),…

> Regardless of any minor difference of opinions, I think what you're trying to bring to the rails community is to be commended.

Thanks a lot, man.

Re: Objectify: A Better Way to Build Rails Applications

#32

Post by aphyr »

jamesgolick wrote: post #6
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..

Mixins/modules and open classes do not separate your class in to multiple components - merely multiple files. As I explain in the article, for separate components to be useful, they have to be "protected" from each other - encapsulation, in other words.

Mixins (well, as they're supposed to be used) do provide encapsulation; specifically, they enforce the boundary between instance scope (e.g. access to instance vars) and method interface. I view them as a part of a coupling continuum:

[instance methods] --- [composed subclasses] --- [mixins] --- [the outside world]

But Modules provide more than that. module_function allows for unattached namespaced functions which can be referenced by full name, relative name, or imported into the local scope. Great way to express functions which are decoupled from instance state--much like the services and policies you're advocating for. It's an under-appreciated aspect of the language, I think.

Re: Objectify: A Better Way to Build Rails Applications

#33

Post by iamgilesbowkett »

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 separating persistence from business models is likely to be your first important step when refactoring for scalability. Fragmenting a User model bloated beyond all hope of sanity is almost a rite of passage at this point.

I often think the only Rails developer who hasn't found ActiveRecord bloat to be an irritation and an obstacle to scaling is DHH, and although that makes his opinion on the subject even more valuable than it would normally be, he doesn't talk about it enough in my opinion. Pretty much everyone else, as far as I can tell, responds to Rails scaling issues by creating services in Sinatra and/or divorcing business modeling from persistence logic.

I want someone to challenge my prejudicial assumption here, most of all because I appear to be saying "Rails can't scale," which is BS, but also because I'm very tempted not to take this discussion seriously at all if it doesn't address this point. It's just the crucial point in my opinion. I like the whole OOP thing but to me the decision to use something like Objectify is all about scalability. That doesn't just mean performance; it also means retaining readability when you have a lot of code. Single Responsibility Principle makes code readable.

Re: Objectify: A Better Way to Build Rails Applications

#34

Post by regularfry »

jamesgolick wrote: post #8
regularfry wrote: post #7

Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"

Because of SRP.

I can see how that will give you a single-method class some of the time, and I'm in absolute agreement as to how it applies to serialisation classes, but I don't see how SRP implies that single-method service and policy classes are the One True Way.

I think I'll have to give objectify a try and see how it all fits together. It's a different enough approach to what I'm used to that I probably don't have a reliable intuition as to how it'll turn out in practice.

Re: Objectify: A Better Way to Build Rails Applications

#35

Post by bcrescimanno »

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…

FWIW, I'm not a Rails developer; so take my comments as you will.

I don't think the problem people seem to have with Objectify is that they see it as a totally invalid solution to a problem--and I agree with your assessment that many people see this problem as very real.

My own take is that I find it disingenuous to call it an Object-Oriented solution to the problem; it's not. That doesn't make it bad, invalid, or wrong. It rightly raises a few eyebrows to talk about effectively calling namespaced procedures as if it were the pinnacle of Object-oriented design.

Re: Objectify: A Better Way to Build Rails Applications

#36

Post by stiff »

jamesgolick wrote: post #27
stiff wrote: post #25

This is not object-oriented at all, unless you learned about object-orientation from Java and its monster frameworks, this is basically a form of data-flow programming. OO is about message passing, here the "objects" do not pass any messages at all, the supposed "objects" _are_ the messages, and the routing of those messages takes place in the configuration in routes.rb, so the objects do almost no message-passing be…

I've read at least a dozen papers on the history of OO, not to mention books and papers on current practices. This is what I came up with. I made what I think is a pretty coherent argument for why in the article. I'd love to hear your refutation of the points I made in there.

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.wikipedia.org/wiki/Dynamic_dispatch

You also don't have encapsulation anymore, since to be able to perform the majority of the work in the services, the services have to operate directly on data owned by other objects.

How can you combine the policies in ways other than a simple logical AND? How do you combine services?

Others have also already pointed out other issues.

Please don't be offended by the above. Software engineering is unfortunately a field where some valuable content is buried underneath loads of BS, since it is so easy to "philosophize" about it even with just basic programming experience and this leads other people learning the field to easy misconceptions. I do not want to discredit the work you put into this and it might be that in some form something valuable will come from some of the ideas. It is an interesting problem to work on and for me it was an interesting solution to think about, I just don't think you are there yet.

Re: Objectify: A Better Way to Build Rails Applications

#37

Post by jamesgolick »

stiff wrote: post #36
jamesgolick wrote: post #27

Earlier quoted context omitted.

I've read at least a dozen papers on the history of OO, not to mention books and papers on current practices. This is what I came up with. I made what I think is a pretty coherent argument for why in the article. I'd love to hear your refutation of the points I made in there.

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.

Re: Objectify: A Better Way to Build Rails Applications

#38

Post by ryeguy »

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.

You need to grow thicker skin, that first sentence was in no way condescending and gives you no reason to just ignore the rest of his comment.

Re: Objectify: A Better Way to Build Rails Applications

#39

Post by telemachos »

ryeguy wrote: post #38
jamesgolick wrote: post #37

Earlier quoted context omitted.

> 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.

You need to grow thicker skin, that first sentence was in no way condescending and gives you no reason to just ignore the rest of his comment.

No. It may be unintentional, but the tone of stiff's comments is highly condescending.

Exhibit A: Whatever you think about James's choices in this library, he has clearly thought a lot about OOP. It's just silly to start a comment with "You have to think a bit more about what OO really is about."

Re: Objectify: A Better Way to Build Rails Applications

#40

Post by phillmv »

ryeguy wrote: post #38
jamesgolick wrote: post #37

Earlier quoted context omitted.

> 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.

You need to grow thicker skin, that first sentence was in no way condescending and gives you no reason to just ignore the rest of his comment.

>You need to grow thicker skin

I'm beginning to be convinced this is almost never an appropriate thing to say.

Post reply on HN