Compte rendu d’une lecture récente. Et super-amusante !
UNIX est un monde en soi, avec ses règles inattendues, son efficacité qui reste à prouver et ses illogismes. Vous qui avez pas mal de bouteille en informatique et qui ne comprenez toujours pas UNIX, lisez la suite ci-dessous… Je ne suis pas sûr que vous comprendrez enfin UNIX, mais en tout cas, vous devriez sourire pas mal de fois !
Dans l’article précédent, nous avons créé une classe Customer et une classe ReadOnlyCustomer. Sachant que le code ne manipule que des objets de type Customer, comment déterminer dans le débuggeur si l’instance d’un objet donné est modifiable (read-only) ou non ? Lire la suite ci-dessous.
Voilà ce que ça donne de passer son temps à regarder le code de .NET dans Reflector : on y trouve chaque jour des façons de faire auxquelles nous n’avions pas pensé !
Ici, une façon simple de founir des objets non modifiables. À lire ci-dessous.
Un petit exercice de style (qui devint avec quelques modifications le code de mon client d’alors). En gros, comment appeler un service Web de type REST avec C# ? Source code provided, comme dirait l’autre…
Il me semble que le moindre logiciel développé sous .NET aujourd’hui compte au minimum 75 namespaces, namespaces dont la longueur moyenne du nom approche facilement les 150 caractères… Je ne compte plus les MaSociete.MonDepartement.MonLogiciel.MonSysteme.MaCouche.MaSousCouche.MaClasse qu’on rencontre toutes les trois lignes. Avouons-le, voilà une façon efficace de rendre pénible la lecture de la moindre méthode…
Mon impression : tout le monde ne semble pas avoir bien compris l’utilité des namespaces, à commencer par Philips (voir 3.2.9) ! Chose certaine, les namespaces ne sont pas là pour encombrer le code de détails superflus. Lire la suite ci-dessous.
Théoriquement, ça n’a pas d’importance. Mais en pratique, ça en a. Lire la suite ci-dessous.
J’ai entendu dire que VB était vachement mieux-mieux sur ce coup-là. Lui seul pouvait redéfinir la portée (le scope) d’un membre d’une interface… Plus précisément : une classe implémentant l’interface XYZ peut, en VB.NET, cacher l’une des méthodes de XYZ tout simplement en la déclarant privée.
Mais ce n’est pas tout à fait vrai. C# le peut aussi…
Cela dit, une interface ne devrait jamais être redéfinie au niveau des classes qui l’implémentent. Il me semble que c’est une question de bon sens : JAVA et EIFFEL ne me semblent pas permettre ce tour de passe-passe…
Lire la suite ci-dessous.
Vous n’êtes pas développeur C# si vous n’utilisez pas allègrement l’opérateur coalescent dénoté ??. Lire la suite ci-dessous.