Talk:Yo-yo problem

From Wikipedia, the free encyclopedia

This was removed from the article.

On the other hand, object-oriented programming methodology is structured around data and data types. If the programmer uses this structure to follow and understand the object-oriented program, the problem disappears, as there will be no need to follow the control-flow structure, except during debugging.

I am not sure about this. This sounds a bit ranting. Does anyone care to clarify this? -- Taku 23:01, Jun 5, 2005 (UTC)

With object-oriented design, control flow is not very important for being able to understand the design, because object-oriented design principles enforce that methods can be independently invoked in any order without changing the meaning of each invocation, which means that all important aspects of the program (that is, class invariants) are preserved even if the methods are invoked in different order. This is also the reason why many object-oriented systems use callbacks, where order cannot be enforced due to lack of information for the caller as to correct order. [Any system that uses callbacks in a way that requires that those callbacks are invoked in certain order is flawed, IMO]. The independence from ordering is ensured by the API design principle that says that methods in each interface should be orthogonal to each other. This is sometimes called the "Operand principle" [see Meyer: Object-oriented software construction ], and it states that a method must not have optional parameters, only mandatory parameters. Sometimes the same thing is also called "Shopping list principle". This principle is implied by the open-closed principle (class should be open for extension but closed from modification), because a class is extensible exactly when all parameters to every method are mandatory. For object-oriented design, more important consideration to order of execution is how stack is used (layering), and how different classes (not objects!) relate to each other. esap 16:53, Jun 6, 2005 (UTC)