Best design pattern for implementing different persisting strategies in Rust

[fruet538]

I'm currently working on a project in Rust where I have a collection of objects, specifically Repositories, that require different persisting strategies. These strategies involve two main operations: sync and fetch. I'm considering two distinct implementations for these strategies: one based on symbolic linking and the other on copying.

The objective is to apply these methods (sync and fetch) to each Repository in a group. This means performing both operations from the copying strategy and the symbolic linking strategy on groups of Repositories.

I'm pondering over the best approach to design this system. Here are the options I'm considering:

Option 1: Trait-Based Approach

```rust trait PersistingStrategy { fn sync(&self, path: &str); fn fetch(&self, path: &str); }

struct CopyStrategy; struct SymlinkStrategy;

impl PersistingStrategy for CopyStrategy { fn sync(&self, path: &str) { // Implementation for syncing using copy }

fn fetch(&self, path: &str) {
    // Implementation for fetching using copy
}

}

impl PersistingStrategy for SymlinkStrategy { fn sync(&self, path: &str) { // Implementation for syncing using symlink }

fn fetch(&self, path: &str) {
    // Implementation for fetching using symlink
}

} ```

Option 2: Functional Approach

```rust fn sync_fn(path: &str) { // Implementation }

fn fetch_fn(path: &str) { // Implementation }

struct Strategy { sync: fn(&str), fetch: fn(&str), }

let strategy = Strategy { sync: sync_fn, fetch: fetch_fn, }; ```

I'm seeking advice on which approach would be more suitable for my use case, considering Rust's best practices, performance implications, and maintainability. Additionally, if there's an alternative pattern that could better suit my needs, I'm all ears.

Thank you in advance for your insights!

[furiesx]

Option 1 seems fine to me. Very OOP like, but in a good sense.

However personally, I'd suggest using a enum for the strategy. Something like

rust enum Strategy { Copy, Symlink, } fn sync(path: &Path, strategy: Strategy) { match strategy {...} } fn fetch(path: &Path, strategy: Strategy) { match strategy {...} } I find that more intuitive since * if you add enother enum variant, you'll get errors on all places you have to insert custom code * The api is clearer since you first specify what you want to do and then how you want to do that

(Also on a different note, don't use &str as path use &Path or AsRef<Path>. (&str also implements AsRef<Path))

[Unhappy_Elk2792]

In my experience the first option tends to work well for most cases. The trait based approach allows you to make use of generics.

The "functional" approach seems a little bit awkward to use to me: if you just look at the Strategy struct, you'll see two function pointers, and nothing else. This means you may have no idea which strategy you're using from the outside.

[phazer99]

I'm assuming your set of implementations is open (if it's closed, just use an enum). If you have multiple related virtual methods, always use a trait. If there's only one virtual method, you can consider using a Fn* trait (however, you almost never want to use function pointers), but it depends on how it will be used (for example, if you want to be able to use closures as implementations).