Differences

This shows you the differences between two versions of the page.

--- principles:uniformity_principle [2021-09-02 12:50] – old revision restored (2021-05-19 09:48) 65.21.179.175
+++ principles:uniformity_principle [2021-09-02 20:49] – old revision restored (2021-05-12 02:44) 65.21.179.175
@@ Line 11: / Line 11: @@
 ===== Principle Statement =====
-Solve similar problems the same way.
 ===== Description =====
@@ Line 50: / Line 49: @@
 ==== Contrary Principles ====
-Note that UP can be contrary to virtually every other principle as it demands neglecting other principles in favor of uniformity.
   * [[Keep It Simple Stupid]] (KISS): Sometimes UP demands more complex solutions because they are already applied elsewhere and for the sake of uniformity shall also be applied in simpler contexts where they would not be necessary.
-  * [[Model Principle]] (MP): UP may demand adhering to a certain naming scheme, which may not be best with respect to MP. See [[#example 1: naming schemes]].
+  * [[Model Principle]] (MP): UP may demand adhering to a certain naming scheme, which may not be best with respect to MP.
 ==== Complementary Principles ====
-  * [[Principle of Least Surprise]] (PLS): When applying UP, PLS should also be considered for naming modules. See [[#example 1: naming schemes]].
+  * [[Principle of Least Surprise]] (PLS): When applying UP, PLS should also be considered for naming modules.
@@ Line 66: / Line 62: @@
 {{page>collections:OOD Principle Language#Box}}
+===== Example =====
-===== Examples =====
-==== Example 1: Naming Schemes ====
-A typical example of the application of UP is the naming of method identifiers for common container classes like [[glossary:stacks]] or [[glossary:queues]]. This also shows that there are several ways to apply this principle.
-Stacks typically have the methods ''push'', ''pop'' and ''peek'' (sometimes also called ''top''). ''push'' puts an item onto the stack, ''pop'' removes the top most item and ''peek'' retrieves the value of the top most item without removing it from the stack. This is how the common stack model describes this data structure (see [[Model Principle|MP]]). Applying UP to this naming decision means that the methods should be named precisely as they are named everywhere else also. So a developer knowing the model or other implementations of the model will immediately know how to use this module as well. In this case MP and UP demand the same thing. [[Principle of Least Surprise|PLS]] is satisfied here as well as a developer knowing stacks will expect exactly that.
-Queues on the other hand typically have the methods ''enqueue'', ''dequeue'', and ''peek'' (or ''front''/''first'' or the like). MP would demand naming the operations of a ''Queue'' module exactly that way. But there are several ways Up can be applied here. The one way is to apply the principle just like above. Resulting in methods ''enqueue'' and ''dequeue''. This is how it is done in .NET((http://msdn.microsoft.com/en-us/library/system.collections.queue(v=vs.110).aspx)). The other way is to consider the method identifiers of the ''Stack'' module. A possible application of UP could be to demand naming the queue methods just like the stack methods, meaning also ''push'', ''pop'' and ''peek''. This is the naming scheme which was chosen in the Delphi RTL((http://docwiki.embarcadero.com/Libraries/XE3/en/System.Contnrs.TQueue_Methods)). Here MP and UP are contrary. A further downside of this approach is that ''pop'' and ''push'' methods might be surprising for a queue class. So PLS would oppose this solution.
-A third possibility is to find a common abstraction and to apply a very general naming scheme to all descendant classes (stack classes, queue classes and others). This is the way it is done in Eiffel((see Bertrand Meyer: //[[http://en.wikipedia.org/wiki/Object-Oriented%20Software%20Construction|Object-Oriented Software Construction]]//, p. 127)). Here there the method names are ''put'', ''remove'' and ''item'' regardless of the concrete data structure. This is contrary to MP but creates a uniform naming scheme throughout the API. So there is less uniformity across APIs but stronger uniformity within the API. MP and UP are here contrary too. For PLS this means that a developer who is used to this philosophy is never surprised by having these methods. But developers new to it might be nevertheless.