Structure du fichier C OOP?

Question

Je viens de commencer à programmer des objets récemment et j'essaie d'apprendre de bonnes habitudes dès le début.

La façon dont je l'intention de structurer ma demande est d'avoir deux fichiers:

1: Program.cs - Ce fichier contient la logique principale pour l'application
2: Class.cs - Ce fichier contiendra toutes les définitions de classes

Assez simple. Ce que je me demande si je devrais avoir d'autres fichiers pour ... eh bien, dites-moi.

Toute aide serait appréciée.

Answer 1

Il est généralement accepté que chaque classe possède son propre fichier.

Program.cs - Ce fichier contiendra la logique principale pour l'application

Je suppose quand vous dites ce que vous voulez dire que la classe principale est dans ce fichier. (La classe avec le point d'entrée à l'application). Les différentes parties de la logique doivent être séparées et placées dans les classes qui ont le plus de sens pour les avoir.

Liens vers objet Design orienté:
http://www.csharphelp.com/2006/05/designing-object-oriented-programs-in-c/

http://www.informit.com/articles/article.aspx?p=101373

Liens vers les espaces de noms:
http://www.csharphelp.com/2006/02/namespaces-in-c/

http://msdn.microsoft.com/en-us/library/dfb3cx8s.aspx

Answer 2

Ma seule suggestion serait de briser chaque classe en classe. cs dans son propre fichier nommé ClassName.cs .

Cela facilitera la recherche et la correction des insectes sur la route.

Moins de code dans chaque fichier = moins de recherche pour trouver le code incriminé.

Answer 3

Chaque classe doit avoir son propre fichier - pas un fichier .cs contenant plusieurs classes. Je ne suis pas sûr, ne l'ayant pas essayé, mais votre IDE peut imposer ceci.

Answer 4

Le principe généralement accepté à suivre est d'avoir un fichier pour chaque classe (ou classe partielle, dans le cas des applications 2.0+). Pour toute application non triviale, vous voudriez certainement et non vouloir toutes vos définitions de classe dans un seul fichier.

Answer 5

Vous devriez jeter un oeil sur ces guidelines

Answer 6

Voici quelques notions de base pour vous aider à démarrer.=)

1. .Net Naming Conventions and Programming Standards and Best Practices;
2. Object-Oriented Concepts;
3. Object-oriented design;
4. C# Coding Style Guide;
5. File Organization
6. Code Convention C#;
7. Design Guidelines for Class Library Developers;

L'architecture de votre solution pourrait ressembler à ceci:

1. Un projet pour vos classes (une classe par fichier);
2. Un projet pour votre accès aux données;
3. Un projet pour votre interface graphique;
4. Un projet pour votre couche d'intégration (tels que NHibernate, EntityFramework, etc.)

Gardez à l'esprit que vous devez faire de chaque morceau de code réutilisable que possible. En écrivant vos objets de gestion (vos classes) dans un projet indépendant, vous pourrez ensuite référencer ce projet dans un autre, vous n'aurez donc plus à recoder toute votre logique métier (méthodes, etc.) et votre activité. objets (classes, énumérations, interfaces, etc.)

La conception orientée objet tente de généraliser tous les aspects pratiques d'un objet et de l'amener à la classe la plus générale pour vos objets métier. Par exemple:

// File: Person.cs 
public class Person { 
    public string Name { get; set; } 
    public string Number { get; set; } 
    // Some other general properties... 
} 

// File: Customer.cs 
public class Customer : Person { 
    public Customer() { 
     Orders = new List<Order>(); 
    } 
    public string CreditTerm { get; set; } 
    public IList<Order> Orders { get; } 
} 

// File: Contact.cs 
public class Contact : Person { 
    public long PhoneNumber { get; set; } 
    public long FaxNumber { get; set; } 
} 

// File: Supplier.cs 
public class Supplier : Person { 
    public Supplier() { 
     Salesperson = new Contact(); 
    } 
    public Contact Salesperson { get; } 
} 

Il est également recommandé de spécifier ce que représentent chacun de vos projets. Prenons par exemple une demande de gestion de la clientèle:

MyCompany.MyCustomerMgmtSoftware.Domain < = Ce projet contient vos classes d'affaires définitions

MyCompany.MyCustomerMgmtSoftware.Data < = Ce projet contient des classes pour l'accès aux données votre DBRM.

MyCompany.MyCustomerMgmtSoftware < = Ce projet contient normalement votre GUI

MyCompany.MyCustomerMgmtsoftware.Mappings < = Ce projet doit contenir vos fichiers de mappage (tout en utilisant NHibernate, par exemple.

cette aide ?