• giving every integer a shared helper method: define a trait with two required methods and one default method,
• Making class AnimatedServo still count as a Servo: require a trait in another trait
• adding a method to a type you don't own: implement a new trait for the primitive type
• giving a tiny Enum a full set of standard behaviors: the standard traits already exist and derive
• making a wrapper feel like the thing inside it: the wrapper can implement the thing and implement Deref and DerefMut
• adding union to any collection of range sets: mock a wrapper around a BTreeSet for example
• treating fifteen integer-link types the same way: to avoid writing the same method bodies 15 times, write a macro_rules
• Giving Only OutputArray<8> (8 bits) a Byte-Oriented Method: implement a general methods in the general impl block. It's named Constraint-Gated Methods.
• How would you make some methods available only when the method’s type parameter has the required capabilities? Use serde and postcard with a HashMap standing in for flash memory.

Plusieurs liens montrant les défauts de la POO.

Je me souvients de mon premier prof d'algo :

le plus important, ce sont les structures de données. Elles font tout dans le programme.

Et c'est vrai. Puis je suis allé en deuxième année, j'ai commencé la POO (c'est le drame car c'est du Java, mais bon). Je me suis dis que lier les fonctions et les données dans un seul objet est une méthode qui fonctionne mais définitivement imparfaite. Avec le retour de plusieurs autres développeurs expérimentés, je pense de plus en plus que cela est vrai.

J'étais partit pour effectuer pleins de références; le mieux est cependant des les lire, quitte à les survoler.