App architecture - play_test modes vs real_mode (production)

A voting application is to be executed in three modes:

  • PlayMode, // Low Security
  • TestMode, // Medium Security
  • RealMode, // High Security

See more details here:

How to structure the Election application?

The Play/test mode has everything that the Real mode has - plus some extra features that are illegal in Real mode.

Should the program generate three binary files? Play/Test/Real? Or, simply separate Play and Test mode from Real mode.

Or - at the beginning (first time execution) have some kind of initialization process and ask user what kind of database / mode is to be created (that cannot be changed later)?

Another option:
Add a flag in the Election structure: mode_type

enum ElectionModeType {
    PlayMode, // Low Security
    TestMode, // Medium Security
    RealMode, // High Security
}

struct Election {
    election_id: u32,
    title: String,   
    election_mode: crate::ElectionModeType, 
}

Appreciate your thoughts and suggestions.

To share the same code across different modes I'd go with something like this to make sure that some behavior is only possible in some mode. With cargo features you can make it possible to pick the desired behavior or behaviors on compile time:

struct Foo<T> {
    votes: usize,
    mode: std::marker::PhantomData<T>,
}

struct Secure;
struct Play;

impl<T> Foo<T> {
    fn cast(&mut self) {
        self.votes += 1;
    }
}

impl Foo<Play> {
    fn stuff(&mut self, cnt: usize) {
        self.votes += cnt;
    }
}

impl Foo<Secure> {
    fn encrypt(&self, key: &[u8]) -> Vec<u8> {
        todo!()
    }
}

impl Foo<T> {
    fn start_play() -> Foo<Play> { todo!() }
    fn start_secure() -> Foo<Secure> { todo!() }
}

To use it - it can be either different command line flags or different executables. For highest security you could check that play mode is not enabled with feature flags for example. You mention some formal requirements - they might have some valuable ideas too.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.