0

I recently read that option-operand separation is a principle that was introduced in the Eiffel language (I've never used Eiffel).

From the Wikipedia article:

[Option–operand separation] states that an operation's arguments should contain only operands — understood as information necessary to its operation — and not options — understood as auxiliary information. Options are supposed to be set in separate operations.

Does this mean that a function should only contain "essential" arguments that are part of its functionality, and that there shouldn't be any arguments that change the functionality (which instead should be a separate function)?

Could someone explain it simply, preferably with pseudocode example(s)?

Mark
  • 18,730
  • 7
  • 107
  • 130

1 Answers1

2

Yes, this is the idea: arguments should not be used to select particular behavior. Different methods (features in Eiffel terms) should be used instead.

Example. Suppose, there is a method that moves a 2-D figure to a given position. The position could be specified using either polar or Cartesian coordinates:

move (coordinate_1, coordinate_2: REAL_64; is_polar: BOOLEAN)
    -- Move the figure to the position (coordinate_1, coordinate_2)
    -- using polar system if is_polar is True, and Cartesian system otherwise.

According to the principle, it's better to define two functions:

cartesian_move (x, y: REAL_64)
    -- Move the figure to the position with Cartesian coordinates (x, y).

polar_move (rho, phi: REAL_64)
    -- Move the figure to the position with polar coordinates (rho, phi).

Although the principle seems to be universally applicable, some object-oriented languages does not provide sufficient means for that in certain cases. The obvious example are constructors that in many languages have the same name, so using options becomes the only choice (a workaround would be to use object factories in these cases).

Alexander Kogtenkov
  • 5,770
  • 1
  • 27
  • 35
  • For this particular example, it seems like the right way, also from a type perspective (coordinate should be either a length or an angle). But what about an argument that selects a sorting implementation (same semantics different implementation)? Or a storage backend (perhaps runtime info)? – Mark Jun 14 '18 at 12:47
  • 1
    @Mark, several options are available: 1) select desired behavior with some service functions before calling the main feature (e.g., `use_quick_sort` and `use_merge_sort` before calling `sort`); 2) pass an explicit argument that controls behavior (e.g., have `connect (db_name: STRING_32; connector: CONNECTOR)` where `connector` would be created for a specific database backend; 3) use polymorphism (e.g., have 2 classes `QUICK_SORTER` and `MERGE_SORTER` implementing the same interface with a feature `sort`); 4) use a factory pattern that will separate setup from main functionality, etc. – Alexander Kogtenkov Jun 14 '18 at 19:42
  • Thanks for the extra info! Wouldn't the second option violate the principle? – Mark Jun 15 '18 at 06:50
  • @Mark, indeed it could violate it, but it does not reveal any details about the database engine, so it seems to be a border case and depends on the architecture of the application. The important difference is also the ability to add and to set new options for the database connector without changing the core call to `connect`. – Alexander Kogtenkov Jun 15 '18 at 10:50