How can I convince people to use proper object oriented Perl?

I have been using an Object-Oriented MVC architecture for a web project, and all the models are OO Perl. But I have noticed a couple on the team are reverting to procedural techniques and are essentially using "objects" as dumping grounds for related functions. Their functions basically read/write directly to/from the database.

What's the best way to开发者_如何学JAVA convince them this is the wrong way? Are there some good tutorials I can get them to read?

I can think of three possible reasons why some team members may not produce nice OO code:

1. They don't care
2. They care, try to do it right but lack skills to do it right
3. They are doing it right, or at least right enough! Some matters of design are matters of opinion. Go back and look at some of your own old code, code that you thought was quite good, there's a good chance that you would revise some of it now.

My approach is to make the assumption that everybody wants to do the job right, so I assume (or pretend to assume) that folks care. One tries to build an ethos of wanting to do it right.

So that leaves building our skills, theirs and yours (and mine). Code reviews seem like one obvious way to do this. Talk about alternatives. Also maybe pair-programming?

OOP is just a tool to accomplish some great things like more reliable, usable and maintainable software. If you can not convince your team to write tests give up with strict OOP.

Are they all out of step with you? Perhaps it's just you who is out of step!

Lest I seem facetious, I mean what are the answers to the following questions:

• What has the team agreed should be the approach?

• Whose responsibility is it to enforce purity? If you don't go for enforced purity, whose responsibility is it to encourage purity? If it's not you, have a look in the mirror and make sure you are not the annoying noob on the team telling the old sweats how to do the jobs they've been doing since you were in Perl baby-clothes.

• What mechanisms do you have in place for sorting out such team issues? Regular code reviews, pair programming, bare-knuckle fights ?

• Asking them to read some tutorials is likely to be a waste of breath. What are your arguments for doing things the OO way? As Boris has observed, OO is not an end in itself, it is only a means to an end, and not the only means.

There are probably more things you want to consider in your situation, but these should get you started.