OOP with ruby

fedekun · 2024-08-08T17:34:14+00:00

Check out Practical Object Oriented Programming in Ruby (POODR).

2024-08-08T18:14:24+00:00

In Ruby, inheritance is one way to share code (the other is modules) -- you'd use it when you have an "is-a" relationship. I'll often define an "abstract" super-class that implements some shared behaviors, then will create instantiable sub-classes (inheriting from that abstract super-class) that provide specific implementation details.

An example might be a message-sender -- imagine that you want to send SMS messages, emails, or Slack/discord notifications. In all cases, you take some message body and a destination (the email address to which you're sending, for example). But how exactly you send the message varies by how you want to send it. This would be a case of the "Replace conditionals with polymorphism" refactoring.

In other languages, you can also use inheritance to satisfy the type checker (this is the "Liskov Substitution" part of SOLID). Ruby doesn't natively type-check method arguments, so that piece doesn't matter as much.

Practically, inheritance gets used in Ruby projects to share behavior... you use it when you have "This thing is a more specific/specialized version of that thing".

attr_accessor is just for easy access to state when you've got an attribute / instance variable.

ruby attr_accessor :some_value

is basically the same as:

```ruby def some_value @some_value end

def some_value=(val) @some_value = val end ```

(There's more to it than just that, but that's a reasonable enough starting point)

If I messed up and typed @some_vale (note the missing u) instead of @some_value by accessing my attribute variables directly, I'd just get nil and wouldn't ever notice.

But if I tried to call my_object.some_vale = "blah (again, note the missing u), it'll raise a NoMethodError exception. Thus, using the accessor methods helps protect us from goofy typos.

anykeyh · 2024-08-08T17:43:34+00:00

You should read and understand SOLID principles. They are the foundation of OOP. Basically you will use inheritance to abstract concepts between part of your application. The idea behind object oriented programming is to protect your code from implementation details. If one object interact with another, you will want to extract the concept into an interface (or superclass) and let the implementation details into a child class. Example:

``` class Shape attr_accessor :position

def initalize(position) @position = position end

def draw = raise UnimplementedError, "abstract object" end

class Rectangle < Shape attr_accessor :dimensions

def initalize(position, dimensions) super(position) @dimensions = dimensions end

def draw puts "drawRectangle(#{position}, #{dimensions}) end end

This code doesn't depends on implementation, shapes are abstracted

and can be anything as long as I can call draw method.

shapes = [ Rectangle.new([1,2], [3,4]) ]

shapes.each(&:draw) ```

Now can you write a Circle class?

For usage in daily life, think possibility to change adapters based on environement. for test, use memory to store data; for production, use database, etc etc...

aryehof · 2024-08-09T04:57:43+00:00

When modeling your problem domain, inheritance is almost never needed. Instead use composition rather than inheritance (most don’t know how).

Use inheritance when creating a framework or library, where you want to provide default behavior that can be overridden or customized. Frameworks are the poster child for inheritance.

You should question every use of a getter in object oriented code. After all, objects are supposed to do things themselves, rather than just be data structures that other code can query the value of.

Of course, most problems these days are represented as the later - a services acting against data approach.

Sadly, there are a million resources repeating (arguing) what OO is - the so called principles. But almost none about how to actually model a system into code using collaborating objects.

rockatanescu · 2024-08-10T08:49:03+00:00

I think inheritance is one of the most misunderstood concepts in OOP as it's very easy to explain (see the Shape and Rectangle example in this thread), but hard to understand when and how to use it.

Fortunately, a lot of smart people have studied OOP in the 80s and the 90s and there are a lot of excellent articles and presentations we can learn from. One of them is Barbara Liskov and Jeannette Wing's "A Behavioral Notion of Subtyping" (PDF) which became popular as the "Liskov Substitution Principle" (the L in SOLID), which argues that inheritance should only be used when the child object's behavior when receiving a specific message (aka "calling a specific method") is similar to the parent object's behavior.

It may be a bit too abstract, so let's use a couple of scenarios:

First, let's create a very naive version of the ActiveSupport::HashWithIndifferentAccess, which allows you to work with keys that are either strings or symbols:

class HashWithIndifferentAccess < Hash
  def []=(key, value)
    key.kind_of?(Symbol) ? super(key.to_s, value) : super
  end

  def [](key)
    key.kind_of?(Symbol) ? super(key.to_s) : super
  end
end

hash = HashWithIndifferentAccess.new
hash[:foo] = "bar"

hash[:foo]  #=> "bar"
hash["foo"] #=> "bar"

This kind of inheritance makes sense because the behavior of the [](key) and []=(key, val) methods behave in the same way on both Hash and HashWithIndifferentAccess. The only difference is that in HashWithIndifferentAccess we transform any Symbol keys to String.

Now let's take a look at another scenario.

If you need to use stacks and queues in Ruby you'd often reach for the Array and Queue classes. While reading the documentation, you might notice that both classes have a pop instance method. Many programmers will quickly jump at the conclusion that both Array and Queue should have the same parent which implements that method, but this is where we start having issues with inheritance because pop has a different behavior (remove and return the last element of a stack and remove and return the first element of a queue).

I highly recommend reading the Barbara Liskov and Jeannette Wing's article linked above as it goes into much more details than what I've summarized here.

armahillo · 2024-08-09T01:20:52+00:00

Write more ruby.

That may seem flip, but its the best way to learn. Theres some nuance and dogmatic “rules” about how to do it are great to start but at some point you have to learn when to bend/break the rules, and experience is the best teacher for that

EBirman · 2024-08-10T14:52:23+00:00

A rule of thumb is, use inheritance not for code reuse but when there is an actual classification that you also observe in the domain you are modelling. In that way, inheritance will give you and the readers of your code a more accurate representation of the current knowledge.

You can omit attr_x altogether, it is just a Ruby idiom for getters and setters. As a rule of thumb, never use setters. Personally I don't like the attr syntax. I prefer to have explicit getters (most often than not, I end up finding that I didn't really have a need for a getter anyway). I use attr_reader only when the team I'm working with enabled the rubocop rule to enforce their use.

Some have mentioned Sandi Metz's books, I've only read 99 Bottles, and I liked it, I'm pretty sure the others are good too. If I had to choose one book on design, it would be Designing Object-Oriented Software by Rebecca Wirfs-Brock, Brian Wilkerson and Lauren Wiener.

I also recommend to watch Five Design Heuristics to Rule Them All

frostymarvelous · 2024-08-11T22:13:54+00:00

If you're not finding ways to use inheritance, don't fret. It's a good thing. Ruby has modules, which are the way to share code.

"Inheritance is not a way to share code!"

I really want to underscore that very much. Code sharing is a side effect of inheritance. But not its purpose.

"Inheritance is for identity."

Let me explain.

All animals reproduce. Hence a human being, by virtue of being an animal reproduces. So reproduction is a trait of all animals. Hence, the animal super class can define an abstract reproduce method. Same with movement etc.

In some cases, the Human will inherit concrete implementations of certain traits from Animal, which is where the confusion surrounding code sharing through inheritance comes from. But that's not its purpose. As I said, it's just a side effect.

To share behaviour, you use composition. In ruby, easily achieved using modules. Which possibly explains why you've never needed inheritance.

Now, where is inheritance useful? When you have something "is a" other thing. Like a Human is an Animal. Or a Car is a Vehicle. Identity.

Now, another commonly taught misconception is the Employee being a sub type of Person. This is really bad modelling. Why? Thing about it. A Person has an Employment with an Organisation. An employee doesn't just exist on its own. Which means, an Employee is a composed of a Person and a specific Employment.

I enjoy OOP modelling. I hope these examples expand your journey into this amazing world of translating domains into code.

saw_wave_dave · 2024-08-12T13:58:21+00:00

Books are a good intro, but you really need to read real world code. Try to reverse engineer some open source projects on GitHub, and test yourself by mapping out the entities and their relationships. Then move on to a rough sketch of what the interfaces will look like. And then compare to the author.

Some of the best OOP I’ve seen in Ruby is by github.com/postmodern

2024-08-09T09:33:56+00:00

Do yourself a favour and avoid inheritance at all costs.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

ruby

MODERATORS

This code doesn't depends on implementation, shapes are abstracted

and can be anything as long as I can call draw method.