0Day Forums
System for organizing multi-file Ruby programs? - Printable Version

+- 0Day Forums (https://0day.red)
+-- Forum: Coding (https://0day.red/Forum-Coding)
+--- Forum: Ruby (https://0day.red/Forum-Ruby)
+--- Thread: System for organizing multi-file Ruby programs? (/Thread-System-for-organizing-multi-file-Ruby-programs)



System for organizing multi-file Ruby programs? - watercoolers919008 - 07-19-2023

Is there a standard or conventional system for organizing multi-file Ruby programs? I have embarked on my first large "project" in Ruby, a search program which is logically organized into multiple files and directories. I've outlined below my potential structure:

- *The main file*. This file implements the search class and general searching protocol.
- *The algorithmic analysis file*. This file implements functions that interpret search results.
- *Protocols directory*
- Contains one file per protocol to search.
- *Feeds Directory*
- Part of the program's purpose is to search archived news feeds. The files for this feature go in this folder.

However, the code currently has a class (let's call it Searcher) that each protocol's search class inherits from (GoogleSearcher < Searcher). In order to manage this, I need to include the main file in these protocol files (right?) which doesn't seem possible given my ideal structure.

Aside from my specific example, I was wondering if there are any conventions, such as "more files rather than less", or "logical structuring of files is unnecessary". Is it common to have a file of "helper" functions (such as in Rails?) What level of abstraction is considered appropriate?

Finally, I'm planning on integrating this into Rails someday as a library (not a plugin; I want it to work standalone as well). I don't know if this would affect the organization.

I know this is a pretty open-ended question, but that's because I would appreciate any advice that is remotely relevant. Thanks in advance.


RE: System for organizing multi-file Ruby programs? - anisatemrhvxpb - 07-19-2023

Besides the recommended links in vonconrad's Answer, you can refer to the section “Organizing your source” in Chapter 16 of [*Programing Ruby 1.9*][book] by Dave Thomas et al. There is a [free sample PDF of that part of the book][pdf-sample].


The chapter mentions:

> **16.1 Namespaces** We’ve already encountered a way that Ruby helps you manage the names of things in your programs. If you define methods or
> constants in a class, Ruby ensures that their names can be used only
> in the context of that class

  

> **16.2 Organizing Your Source** Small, self-contained scripts can be in a single file... *bigger programs should consider the RubyGems system*

anagram/ <- top-level
bin/ <- command-line interface goes here
lib/ <- three library files go here
test/ <- test files go here

[book]:

[To see links please register here]

[pdf-sample]:


RE: System for organizing multi-file Ruby programs? - kahoolawe922597 - 07-19-2023

You may want to consider creating a gem for your library. This would make it easy to use the library both stand-alone and with Rails, as well as make deployment/updates simpler.

Further, because gems normally follow a specific directory structure, it also solves your issue of not knowing how to organize the library.

There is plenty of documentation available for creating gems. [Here][1]'s a bit more info about file structure, as well as other useful tips.


[1]:

[To see links please register here]




RE: System for organizing multi-file Ruby programs? - enchiridion348667 - 07-19-2023

I know this question is quite old, but will hopefully be of use to those who come after...

I agree with what's been said above: gems are a great way to organize and reuse code.
In addition to the links above, may I recommend using Bundler to create gems as outlined
in this Ryan Bates RailsCast:

[To see links please register here]


I find that Bundler makes gem creation and maintenance very straightforward.

Regarding inheritance, check out how Ruby mixins can be used to encapsulate and reuse code
across disparate class hierarchies.

[To see links please register here]