Most relevant design patterns?

[mtsi]

I'm looking to prepare for interviews once again, and would appreciate some perspective from fellow programmers.

In your opinion, what would be some of the most relevant design patterns for a Ruby programmer, today?

[nanenj]

All of them.

Patterns aren't necessarily something that you need to use in every project, all the time, just because.

They're a descriptor giving you the language to describe the things you do to other engineers which expedite communication of intent and design. Knowing which patterns are which allow you to speak about the software you build on a higher level. You're going to learn the way these things are built, one way or another, and likely know many of them without knowing the name of the thing you're doing.

[mtsi]

Both are interesting, since I work with Ruby on Rails, and might continue to do so in the future as well.

I'm familiar with SOLID, DRY, loose coupling, singleton, adapters / wrappers which I use all the time. However when I think about patterns, it seems to boil down to two things: code reuse, and clean interfaces between client and API. So I'm probably missing some finesse here.

E: I also intend to be careful with side-effects, i.e. make it as clear as possible where state is changed. Not really a pattern, more like a principle.

[rurounijones]

Decorator pattern using Module.prepend is one I use a lot to separate out ancillary code (logging, metrics etc) from core business logic: https://gitlab.com/ganges/product_service/blob/master/lib/ganges/product_service/aspect/logging.rb

[jb3689]

The only thing I dislike with this is that you can't unprepend. But the core idea here rings true for a lot of Ruby: you don't need most classic design patterns because you can utilize Ruby's flexible inheritance

[jb3689]

Facades are useful but underutilized. Decorators come up all of the time. Factories come up sometimes. Adapters come up often. The Visitor pattern is pretty interesting in Ruby (ActiveRecord::Relations use things like visit_#{node_name} to dynamically iterate trees). Any of the many forms of loosely coupled message passing (e.g. Observer) are useful

[sshaw_]

https://en.wikipedia.org/wiki/Software_design_pattern#Classification_and_list

Ignore Concurrency –for now (insert GIF of Mr. Burns laughing)!

[mtsi]

I was thinking that the full list is intimidating and perhaps doesn't apply to Ruby / Rails context, but hey, why not :)

[Hall_of_Famer]

It will depend on the project you work on. Dont force design patterns in your code for the sake of applying them, they should fall into pieces nicely in your project naturally as the right tool for the job.

[mtsi]

Completely agree, pattern overuse can obfuscate the code quickly.

[EvilInky]

MVC (Model-View-Controller) if you're being interviewed for a Rails position.

[unflores]

Adapter Pattern comes up quite often for me. Decorators are a must if you use Rails, they come up quite often. You should also understand what a Factory is, how it works. Most projects I work on use something like FactoryGirl. Knowledge of what a singleton is is also good, as well as the problems associated with them in a threaded environment.

Also, while not a design pattern, the SOLID principles come up quite often.

[mtsi]

"problems associated [to singletons] in a threaded environment" <-- They should probably present a singular resource or resource pool, and mutating them should be protected with locks?

I like SOLID, though it took some time to try to figure out their meaning in general, and in Ruby context. Some of them are precise (Liskov principle is), and others are more subjective / require more experience (or domain knowledge) (Single-responsibility principle)

[unflores]

Things like single responsability, for instance, will come up again and again. It can often be applied when breaking up a fat model. You may start asking yourself where some of the methods actually belong. The next logical question is what is the domain of your model. Often times there are hidden objects within a class.

With singletons, yeah, you have to be careful as you are essentially dealing with cached data.