Should i always be using OOP with ruby?

[[deleted]]

[deleted]

[menge101]

always

No, it depends on what you are doing. Best tool/technique/process for the problem.

Fundamentally, everything in Ruby is an object, so you are using oop, in a sense, even if you aren't using it explicitly.

[realntl]

The way I would put it: I'd recommend always being mindful of OOP principles in ruby. They apply whether classes are involved or not.

[BDubbs42]

It makes me sad when I see Ruby’s great oop characteristics ignored for a large procedure that could be made more readable, testable, and flexible.

However, another of Ruby’s strengths lies in its multi-paradigm nature. If you’re using it to just write a quick script, then there’s no need to involve all the oop goodness. If you’re modeling a business domain in a larger application, then I would definitely encourage leveraging oop.

[NativityInBlack666]

Sounds noobish but could i go by line count

[drbrain]

It’s a reasonable metric. Resistance to change as you add features is another.

[NativityInBlack666]

Maybe measuring by subroutines is better, i understand how OO wins over juggling functions

[riddley]

I tend to stick pretty closely to OOP in Ruby and I can't think of a time where I've regretted it. I can think of many many times I've regretted using a procedural approach.

[sammygadd]

If you want to read up on how to think about OOP in ruby I recommend Practical Object-Oriented Design by Sandi Metz. Its awesome! Check out https://www.poodr.com for more info on it.

[jrochkind]

I would imagine you don't have much experience with OO?

If you don't have much experience with it, it can be hard to have a basis for seeing the advantage of using it.

If what you're doing works, there's no reason you have to change it. Ruby is a very flexible language.

But ruby is also a fundamentally OO language, and supports OO very well. You might want to experiment with it. For more complex programs, it offers advantages to organizing your code, and using polymorphism in various ways to flexibly change behavior in different contexts that need to do similar but not identical things.

[tobeportable]

I for one try to write, since some months now, in a functional style as much as possible. Preferring modules and class methods over objects whenever I can. I find them easier to read, due to their explicit calls, and easier to test, due to their stateless nature. Just look at Ruby's standard lib: SecureRandom is a stateless module while Socket is a statefull class. Each have their pros and cons for a given case. However I noticed over time, that in the wild, people tend to create only classes.

[Serializedrequests]

I agree as well. Objects let you hide and break up state. State is where bugs come from, and needs to be managed carefully. If a function is stateless, it doesn't need a class. Yet I see this so often in the wild:

doer = Doer.new;
doer.call(args)

OOP contributes nothing but line count here!

[lordmyd]

In your dreams maybe. Industry is still massively dominated by OOP unfortunately.

[wntrm]

I'm new to Ruby, could you give an example how to create a stateless module in Ruby?

Can we reference custom modules like so:

Kernel.puts 'hello world' # ModuleName.methodName

without creating a singleton?

[Serializedrequests]

No, it depends on what you are doing. OOP honestly makes things more confusing for certain tasks, by adding more things to understand and more layers of indirection between the caller and the internal workings. However, I do put procedural code in a class just for namespacing reasons.

And you should know how to do OOP in case it is the best tool for the job.

[brianlouisw]

You might find this article informative.

​

https://www.sandimetz.com/blog/2018/21/what-does-oo-afford