Est-ce que tout est un objet en .NET et C# ?

In .NET and C# all is object.

Simply said.

Even a value type, a struct, an interface and an enum.

One can not approve, but the point is that everything is object, except pointers/references, and literals from binary files, even CPU optimized primitive types, since it is the OOP Theory as well as the. NET specifications and therefore the facts.

Lire la suite »


Que sont les classes et les interfaces en C# ?

Interfaces are to make an abstraction, an archetype, of the abstraction, the classes, of the reality, the objects.

Interfaces are to specify contract terms without providing implementation provided by classes.

Lire la suite »


Qu'est-ce que le polymorphisme en POO ?

Polymorphism in OOP Theory is the ability to:

  • Invoke an operation on an instance of a specialized type by only knowing its generalized type while calling the method of the specialized type and not that of the generalized type: this is dynamic polymorphism.
  • Define several methods having the save name but having differents parameters: this is static polymorphism.

The first if the historical definition and the most important.

Lire la suite »


Qu'est-ce que l'encapsulation en POO ?

Encapsulation in OOP Theory is the process to mask some properties and operations in the class that will become inaccessible from the exterior: these are only internal things and behaviours like a digestive system.

It's a compartmentalization.

Lire la suite »


Qu'est-ce que l'abstraction en POO ?

Abstraction in OOP Theory consists in retaining only the relevant aspects of a real world object for a specific problem.

Thus we talk about abstraction of the reality.

It's a reduction.

Lire la suite »


Comment améliorer ses connaissances en C#

Étudiez le code des logiciels que vous aimez que vous pouvez trouver par exemple sur CodeProject, GitHub, GitLab, SourceForge, etc.

Essayez de faire des logiciels similaires et adaptez-les, sans plagier en dehors de l'apprentissage personnel, comme un bloc-notes, une calculatrice, un explorateur de fichiers, un gestionnaire de banque... ou un jeu.

Écrivez du code, ne vous arrêtez pas pour écrire.

Et surtout, lisez et relisez des livres.

Personnellement, j'aime les livres de Wrox (Wiley), ils sont très bons : n'hésitez pas à lire même des livres anciens si la version plus récente n'est pas disponible.

Les cours en ligne sont excellents aussi, mais ils ne remplacent pas les livres et le code source ou la formation professionnelle.

Pour pouvoir comprendre des sujets avancés et approfondis liés à la programmation et à la nature des ordinateurs, nous devons aller à l'Assembleur, non seulement à l'IL, mais à l'assembleur natif et au code machine.

Lire la suite »


Les interfaces sont-elles un fléau ou sont-elles mal utilisées ?

There are several considerations and practices concerning interfaces

Some developers say that interfaces can be used as a replacement of multiple inheritance mechanisms, which cause complexity and ambiguity. But each feature must be implemented each time it is declared: this is not an inheritance, this is a wrapper to the description of a part of a group of classes, like IDisposable. It is the same as a multiple inheritance with one implemented class and some abstract classes: it is a particular case which allows only one way hierarchy with interfaces as abstract connectors that describes services.

Some developers say that interfaces can be used to separate the access to an object of this instance. Historically, interfaces are a COM & DCOM heritage: they are used to manipulate components services, whatever objects are, where they are, and how they are implemented. Interfaces are not a replacement to multiple inheritance, they are something else.

Recommended articles:
A plea for full multiple inheritance support in .NET
A Typed Intermediate Language for Compiling Multiple Inheritance

Lire la suite »


Les défauts d'implémentation du pattern singleton

The paradigm

Consider this common singleton pattern implementation:

public class Singleton
{
static private readonly object locker = new object();

static public Singleton Instance
{
get
{
lock ( locker )
{
if ( _Instance == null ) _Instance = new Singleton();
return _Instance;
}
}
}
static private volatile Singleton _Instance;

private Singleton() { }
}

The problem is that you can inherit this class and create a public constructor if there is no private constructor. Furthermore, static members are allowed. This is no longer a singleton at all. Setting the class as sealed can be an acceptable solution, but you must implement singleton by singleton, i.e., more than ten lines. Thus, coding a such singleton can be the source of many errors and difficulties. Thinking with factoring is not only an agile principle, it is a mathematical theorem.

Defining a generic singleton

A generic solution is to check the absence of static members and that there is only one parameterless private constructor, or an exception is thrown. Singletons that inherit this class can't be inherited and must be sealed. Moreover, the implementation of singleton types are checked at program startup. Therefore, it is not the best solution, but the only thing to do is to create one parameterless private constructor, no static members, and seal the class.

  Generic Persistent Singleton Sample

Taille : 53,4 Kio
Mise en ligne : 28 juillet 2009
Mise à jour : 8 septembre 2015
Dernier téléchargement : 18 mars 2024
Nombre de téléchargements : 561

Lire la suite »