Normes 101 – De l’usage des classes sealed en C#
Wednesday, September 16th, 2009C’est bien beau de ne pas parler des dessous de la robe de la mariée, mais est-ce vraiment utile ? Lire ci-dessous pour la suite.
C’est bien beau de ne pas parler des dessous de la robe de la mariée, mais est-ce vraiment utile ? Lire ci-dessous pour la suite.
Voici une curiosité de C#. Nous nous attendons à ce que this, dans un objet de type référence soit une référence. Et qu’il soit éventuellement une valeur dans un objet de type valeur.
Eh bien, c’est juste le contraire !
Ben voilà : vous avez deux objets en mains, X1 et X2, et vous vous demandez s’ils sont égaux… Ou s’il s’agit du même… Comment faites-vous ? Lire ci-dessous pour quelques pistes.
L’un des seuls reproches que je peux faire à Visual Studio est la présence de commentaires en XML… Déjà qu’ils n’étaient jamais mis à jour en texte à peu près libre, je ne vois pas qui prendra le temps de jouer avec des tags XML en plus (sauf les rares développeurs d’API, bien sûr !).
Cela dit, si vous trouvez comme moi que les commentaires ne sont pas assez mis en évidence dans Visual Studio, vous pouvez toujours faire comme moi. Lire ci-dessous pour la suite.
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.