Comments on Andrzej on Software: Yes, Nick - class methods are evil

What's really wrong with class methods? I just...

2011-07-22T15:42:51.681+02:00

What's really wrong with class methods? I just see them as alternative initialization points, or an alternative to a separate Factory Class, they're not evil per se.

"OO-purity" is not really a perfect measurement when you're using a mixed-paradigm language.

I believe we should focus our energies on writing elegant implementations of class methods, not unelegant-but-by-the-books factories.

Although I like your point of view Andrzej, I also...

2011-07-22T10:18:22.856+02:00

Although I like your point of view Andrzej, I also think as Jeremy, that AR class methods are "special constructors". What's the difference between User.new and User.find(id)?

Unless you always write something like Game.new_user, than ok - it makes sense :)

I fail to see why you would want to create a manag...

2011-07-21T20:25:55.703+02:00

I fail to see why you would want to create a manager object. You're adding overhead where it is just not needed. When looking at AR its better to think of the class methods as specialized constructors, you get an object, or collection of objects back. It is a clean way to mimic a repository pattern. Your suggestion really just adds extra cost to the system, at what real benefit?

Test: "I don't see what is to be gained ...

2011-07-21T19:53:45.868+02:00

Test:

"I don't see what is to be gained by trying to introduce a factory/builder layer into your app just to avoid calling a class method."

It's a matter of personal approach to clean code, object orientation and readability. I prefer shop.products because it makes sense to me and because this is how I view the business domain - there are products in the shop.

Other people may prefer Product.all because they think of it in a more global way or because what they are modeling is not the business domain but the database below.

Similarly, I prefer shop.add_product as way of, well adding new product to the shop. You may prefer Product.create(..)

They way I was taught object oriented programming and the way I practice it is that when a noun appears very often in the conversation with the client or in the documentation then it should be a sign that there must be an object or class representing this concept.

When I work on e-commerce projects then the noun Shop appears very often. Makes sense to have a class from it. When I talked to the customers the concept of adding a product to the shop appeared quite frequently, so shop.add_product(..) makes sense to me.

I use OOP to help me represent the business domain in the source code. The better I do it, the less mistakes I may have.

I don't see what is to be gained by trying to ...

2011-07-21T17:42:38.839+02:00

I don't see what is to be gained by trying to introduce a factory/builder layer into your app just to avoid calling a class method.

First of all, classes are objects so class methods really are instance methods on an object. There really isn't anything special about them other than that the classes themselves are singletons.

The way I like to look at it is that the User ActiveRecord class is the factory/builder for creating User objects and a pretty logical place to put the necessary code. Ultimately the code needs to live in some method somewhere.

Alex: "Actualy I like very much ActiveRecord...

2011-07-21T13:37:07.347+02:00

Alex:

"Actualy I like very much ActiveRecord approach. It's convenient to think of AR classes as database tables. It makes working with relational DB more transparent and OO."

Thanks for your comment. Yes, exactly, AR is perfect for working with relational DBs and make them a little more OOP.

In my opinion AR doesn't scale very well (in terms of the project size, not the speed). Its object orientation is limited and doesn't let you design you project easily. Things like DCI should help here, though.

Marcin: What's the difference between Product...

2011-07-21T13:34:02.211+02:00

Marcin:

What's the difference between Product.objects.get(id=14) and Product.find(14). Is it the same?

The idea of a manager object sounds good. Need to read more about it.

As for madeleine, it's not very mature and stable, be careful and don't use it in production :)

For me Django looks more like this example Shop.pr...

2011-07-21T13:25:45.001+02:00

For me Django looks more like this example Shop.products, you have a Product.objects.get(id=14). And with all those filters and so one it's a very nice approach for me. This objects methods are served by special Manager object, it recalls me something like EntityManager in JPA.
Madeleine sound quite interesting, I'm gonna try it soon - thanks for a tip ;)

Actualy I like very much ActiveRecord approach. It...

2011-07-21T13:13:24.275+02:00

Actualy I like very much ActiveRecord approach. It's convenient to think of AR classes as database tables. It makes working with relational DB more transparent and OO.
Thanks for all your posts btw.

Marcin: I never used Django, but from the link I ...

2011-07-20T23:31:29.640+02:00

Marcin:

I never used Django, but from the link I can't see why it could be better. It's similar to ActiveRecord.

As for the real ORM, I haven't found anything really good in my career. I think that the problem is inherent to ORM, you just can't do super-nice OOP with relational databases behind your app.

I was most happy when I was using Prevayler with Java, and now when I experiment with Madeleine with Rails. Those are not real databases, you just keep objects in RAM and serialize them to the disk.

Once you stop using class methods then even ActiveRecord can give you some OOP background.

So from the other side... Which ORMs could you guy...

2011-07-20T23:14:44.762+02:00

So from the other side... Which ORMs could you guys recommend as almost ideal in terms of pure OOP way of thinking? I was only dealing with PHP, Java, Python and Ruby ORMs.
Based on experience, in my opinion - Django has the most useful ORM with nice, object concept (but I didn't dive into the core so correct me if I'm wrong ;)). Samples of quering in Django - https://docs.djangoproject.com/en/dev/topics/db/queries/

classes is not "global". constants is ...

2011-07-20T22:53:15.476+02:00

classes is not "global". constants is global

Yep, I agree. Class methods on Rails models are al...

2011-07-20T22:24:47.909+02:00

Yep, I agree. Class methods on Rails models are almost always an indication that someone has been thinking in SQL instead of in objects.

Bartosz: "I'd say active record pattern ...

2011-07-20T21:09:03.671+02:00

Bartosz:

"I'd say active record pattern is a different story and doesn't really represent the rest of OOP in ruby world."

When you work with Rails and ActiveRecord, then you have to use the ActiveRecord-style OOP which to me is just sql but with nicer DSL.

Just to be clear, I prefer ActiveRecord than using SQL directly. I'd love if there was a way of using better OOP with Rails, but the ideas presented in the post is the best I could find. I know it's not ideal.

I think that it also happens to more experienced developers that after a few years of ActiveRecord programming you're almost unable to do proper OOP, without globals, static methods etc.

Nice examples 1 and 2 of trying to escape AR patte...

2011-07-20T21:00:12.810+02:00

Nice examples 1 and 2 of trying to escape AR pattern to be more OO.
Although, fighting rails conventions usually ends up bad, maybe these techniques don't fight them as much. Too early to judge for me, without more experimenting with them.

Hey Marcin, thanks for your comment! I agree, the...

2011-07-20T20:55:28.201+02:00

Hey Marcin, thanks for your comment!

I agree, the second way is not really nice, however it doesn't have the performance impact the first one has.

Indeed, that's kind of a facade pattern here. I simply prefer the object-oriented thinking.

To me shop.products is clearer that Product.all and is worth the additional layer. It simplifies designing and thinking what should belong where - just think of it as modeling the domain with objects.

Class methods are sometimes misused but I wouldn&#...

2011-07-20T20:46:20.315+02:00

Class methods are sometimes misused but I wouldn't say they are evil.
Definitely not like static methods in Java were evil.

I've seen many times (and possibly even used sometime) class objects used as singletons and class methods used as singleton methods. Not perfect in terms of OOP, but not as painful either (as it was in Java :). Still testable and maintainable.
As long as a singleton object doesn't mix multiple responsibilities.

I'd say active record pattern is a different story and doesn't really represent the rest of OOP in ruby world. Maybe that's why some ruby programmers, having mostly experience with AR code, complain about class methods so much.
As you mentioned, in AR a class object represents a sql table, while and instance represents a row in that table.
This way, AR class fullfils at least responsibilities of a factory and of a collection. This often leads programmers to put all other methods related to managing objects of a class inside a class.
This end up with massive AR classes with dozens of methods.
Rails convention of "thin controllers, fat methods" multiplies this effect when (and actually very often) misunderstood.

This is often done by new programmers who started their OOP career with Rails, without having good OOP experience before.

If you consider evil as "in danger of being used by inexperienced OO programmer" to write evil code, then sure, it's evil :)

Let me put some of my thoughts here if you don'...

2011-07-20T20:25:47.495+02:00

Let me put some of my thoughts here if you don't mind.

I completely don't get why your approach is better than using class methods. I'm trying to avoid using class methods as much as I can, but it does not look for me like a solution.

Second way it's just a running away and hiding class method invocation into wrapper object. It does not solve problem with avoiding class method calls.

First way is a bit better but...
game.find_user(4) is pretty similar to User.find(id). It does not changing my way of thinking to be more object-oriented than sql. It's just recall me a facade pattern.

What is more I think User.find(id) is much more flexible when you have more than 100 tables with a lot of relations, data, millions users. Every additional join is not desirable then and having one entry point like 'game' object could be a pain. Especially when you have to just get Pet.find_by_user(id).

But after all is a really cool discussion. Big kudos to both of you guys!