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

11–20 of 72 posts

Re: Objectify: A Better Way to Build Rails Applications

#11

Post by jamesgolick »

rbxbx wrote: post #9
jamesgolick wrote: post #8

Earlier quoted context omitted.

Because of SRP.

At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent. Care to give an answer better than "some book some java dudes wrote 20 years ago said so"? While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO non…

I gave an answer better than that. Did you read the post?

Re: Objectify: A Better Way to Build Rails Applications

#13

Post by manuscreationis »

rbxbx wrote: post #9
jamesgolick wrote: post #8

Earlier quoted context omitted.

Because of SRP.

At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent. Care to give an answer better than "some book some java dudes wrote 20 years ago said so"? While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO non…

> Is not instantiation etc a cross-cutting concern that violates SRP in this instance?

Right.

Which is why hes also recommending the use of DI.

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.

It's difficult to internalize until it's bitten you on the ass, hard.

That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).

Re: Objectify: A Better Way to Build Rails Applications

#14

Post by kreek »

Isn't this the command pattern, except instead of 'execute' you use 'call'?

Update: not saying that's a bad thing I used to be a Flex developer and all the frameworks used MVCS (Robotlegs being my favorite). Controllers are all commands and Services are used to retrieve data.

Re: Objectify: A Better Way to Build Rails Applications

#15

Post by brunoc »

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.

No doubt - That's just good OOP. Looks like this gem will help people achieve that.

Re: Objectify: A Better Way to Build Rails Applications

#16

Post by manuscreationis »

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

I disagreed with him then, and still do. People like to claim that OOP breeds cargo cult programming and overly cumbersome abstractions upon abstractions (and it can), but some times you really do need that kind of approach to make a large scale project testable and maintainable.

I'm glad to see there are Ruby devs who can see the value in using these kind of approaches. I honestly believe it's the kind of thing you think is a major waste of time, until you are shown the benefit first hand, and you experience the change. Then you start to understand that by spending a significant deal of time up front building your infrastructure, you can save a lot of time down the road.

I know that's how it was for me years back.

Re: Objectify: A Better Way to Build Rails Applications

#17

Post by jamesgolick »

manuscreationis wrote: post #13
rbxbx wrote: post #9

Earlier quoted context omitted.

At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent. Care to give an answer better than "some book some java dudes wrote 20 years ago said so"? While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO non…

> Is not instantiation etc a cross-cutting concern that violates SRP in this instance? Right. Which is why hes also recommending the use of DI. 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…

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

> That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).

I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).

Re: Objectify: A Better Way to Build Rails Applications

#18

Post by stiff »

rbxbx wrote: post #9
jamesgolick wrote: post #8

Earlier quoted context omitted.

Because of SRP.

At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent. Care to give an answer better than "some book some java dudes wrote 20 years ago said so"? While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO non…

I think you misunderstood each other, you meant a global method and Mr. Golick seems to have understood that you mean just another method in the controller or whatever.

Also, those are not really single-method classes, but single-method interfaces. Since you didn't give any arguments, I don't see how those two extra lines to define a class have any disadvantage in comparison to a global method, and having the framework define a interface to program to leaves more flexibility to the framework user than having the framework accept a method name or block instead. The instatiation of the class can be left to the framework user (in general, I don't know if this is the case here in particular) so that additional data can be attached, inheritance can be used (yes, inheritance has its problems, still it also has plenty of valid usage scenarios), methods broken down into smaller private methods etc. Also in Ruby there are no global methods like you would have in Python or C++, you always define a method of some class, even if it's in the top-level scope - files almost always correspond to individual classes so it would be pretty odd to have methods used here instead.

Re: Objectify: A Better Way to Build Rails Applications

#19

Post by aamar »

Probably worth bringing up Steve Yegge's 2006 "Execution in the Kingdom of the Nouns": http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

I don't think there is a single right answer that is applicable in all cases. But over time, I've come to believe that as a default, code works well when it resembles how you'd ideally explain the service to an extremely intelligent, non-technical person with domain experience. This makes for code that is easy to understand, collaborate around, and modify given changing objectives.

That means creating "Policy" and especially "Service" models--extra nouns--very sparingly. For example, an Elevator was once a nounification of a verb, but people understood it, so it makes sense as a class. ElevatorDoor's good too, but ElevatorDoorOpeningService is probably not good. This is absolutely at odds with strict application of the Single Responsibility Principle.

Re: Objectify: A Better Way to Build Rails Applications

#20

Post by tnm »

rbxbx wrote: post #9
jamesgolick wrote: post #8

Earlier quoted context omitted.

Because of SRP.

At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent. Care to give an answer better than "some book some java dudes wrote 20 years ago said so"? While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO non…

"some book some java dudes wrote 20 years ago" — If you're referring to "Design Patterns", the Gang of Four were writing about C++, it was 1994, and Java wasn't out yet.
Post reply on HN