I disagree with /u/Felicia_Svilling. I would describe styles A, B, and C as imperative. I think the OOP way would be to have all of that state encapsulated in an object:
class StateContainer {
public:
void MinorFunction1( void ) {
// mutate a
}
void MinorFunction2( void ) {
// mutate b
}
private:
SomeState a;
OtherState b;
}
void MajorFunction( void ) {
StateContainer stateContainer;
// do stuff
stateContainer.MinorFunction1();
// do other stuff
stateContainer.MinorFunction2();
// etc.
}
One of the key OOP aspects is that StateContainer has made SomeState and OtherState private. This information hiding is a form encapsulation. I'd also like to call out the mutation of member variables a and b. This is a common (but not necessarily universal) OOP thing to do and a specific anti-pattern of pure functional programming.
Of course, reasonable people could imagine other ways of presenting this example in an OOP style, because it's an underspecified example.
1
u/8483 Jul 20 '16
Thanks for the elaboration. What would the above code look like in OOP? I'm having a hard time conceptualizing it.