C# OOP File Structure?

Question

Hey SO,

I just started programming with objects recently and am trying to learn good habits early on.

The way I plan to structure my application is to have two files:

1: Program.cs - This file will contain the main logic for the application
2: Class.cs - This file will contain all of the class definitions

Pretty simple. What I'm wondering if I should have any more files for ... well, you tell me.

Any help would be appreciated.

Answer 1

It's generally accepted that each Class should have it's own file.

Program.cs - This file will contain the main logic for the application

I am assuming when you say this that you mean that the main class is in this file. (The class with the entry point to the application). The various parts of the logic should be separated out and placed in the classes that make the most sense to have them.

Links to object oriented design:
http://www.csharphelp.com/2006/05/designing-object-oriented-programs-in-c/

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

Links to namespaces:
http://www.csharphelp.com/2006/02/namespaces-in-c/

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

Answer 2

My only suggestion would be to break each class in Class.cs into its own file named ClassName.cs.

It'll make finding and fixing bugs easier down the road.

Less code in each file = less searching to find the offending code.

Answer 3

Each class should have its own file - not one .cs file containing many classes. I'm not sure, not having tried it, but your IDE may enforce this.

Answer 4

The generally accepted principal to follow is to have one file for each class (or partial class, in the case of 2.0+ apps). For any non-trivial application, you certainly would not want all of your class definitions in a single file.

Answer 5

You should take a look on these guidelines

Answer 6

Here are some basics to help you get started. =)

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;

The architecture of your solution might look like this:

1. One project for your classes (One class per file);
2. One project for your data access;
3. One project for your GUI;
4. One project for your integration layer (Such as NHibernate, EntityFramework, etc.)

Bear in mind that you must make each piece of code as reusable as possible. Doing so by writing your business objects (your classes) into an independant project will allow you to reference this project into another one later on, so you won't have to recode all of your business logic (methods, etc.) and your business objects (classes, enumerations, interfaces, etc.)

The object-oriented design is trying to generalize every practical aspect of an object and bringing it to the top most general class for your business objects. For instance:

// 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; }
}

It is also recommended to specify what each of your projects stand for. Let's take for instance an application for Customer Management:

MyCompany.MyCustomerMgmtSoftware.Domain <= This project shall contain your business classes definitions

MyCompany.MyCustomerMgmtSoftware.Data <= This project shall contain classes for data accessing your DBRM.

MyCompany.MyCustomerMgmtSoftware <= This project normally contain your GUI

MyCompany.MyCustomerMgmtsoftware.Mappings <= This project should contain your mapping files (while using NHibernate, for instance.

Does this help?