Lära Principles of Class Design | Class Design and Encapsulation

When you design a class in C#, your goal is to create code that is easy to understand, maintain, and reuse. Good class design starts with a few key principles: each class should have a single responsibility, names should be clear and descriptive, and different concerns should be separated into different classes. By following these principles, you make your codebase more robust and easier for others (and your future self) to work with.

Definition

The Single Responsibility Principle (SRP) states that a class should have only one reason to change, meaning it should have just one job or responsibility.

Program.cs


              123456789101112131415161718192021222324252627282930313233343536373839
            
using System;

namespace ConsoleApp
{
    public class Address
    {
        private string street;
        private string city;
        private string postalCode;

        public Address(string street, string city, string postalCode)
        {
            this.street = street;
            this.city = city;
            this.postalCode = postalCode;
        }

        public string GetFullAddress()
        {
            return $"{street}, {city}, {postalCode}";
        }

        public string GetCity()
        {
            return city;
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Address address = new Address("123 Main St", "Springfield", "12345");
            Console.WriteLine("Full Address: " + address.GetFullAddress());
            Console.WriteLine("City: " + address.GetCity());
        }
    }
}

In this example, the Address class is designed with clarity and purpose. Each field—street, city, and postalCode—represents a specific piece of address information. The constructor ensures that every Address object is created with all the information it needs. The methods GetFullAddress and GetCity provide clear, focused ways to access address data, following the idea that a class should do one thing well and expose only what is necessary.

GodObject.cs


              1234567891011121314151617181920212223
            
// This is a non-runnable code sample showing a poorly designed class.
public class GodObject
{
    public string Name;
    public string Address;
    public int Age;
    public double Salary;
    public string Department;
    public string PhoneNumber;
    public string Email;
    public string Manager;
    public string Project;
    public string Notes;

    public void SendEmail(string message) { /* ... */ }
    public void CalculateSalary() { /* ... */ }
    public void AssignProject(string project) { /* ... */ }
    public void UpdateAddress(string newAddress) { /* ... */ }
    public void PrintEmployeeInfo() { /* ... */ }
    public void ScheduleMeeting(string time) { /* ... */ }
    // ... many more unrelated methods and fields
}

When you compare the clean Address class to the messy "GodObject" above, the difference is clear. The GodObject tries to handle everything—employee data, communication, scheduling, and more—all in one place. This makes it hard to understand, test, and maintain. To improve a class like this, break it down: give each class a clear purpose, use meaningful names, and separate unrelated concerns. This leads to code that is easier to read and less likely to cause problems as your project grows.

Var allt tydligt?

Tack för dina kommentarer!

Avsnitt 2. Kapitel 1

Fråga AI

Fråga vad du vill eller prova någon av de föreslagna frågorna för att starta vårt samtal

Suggested prompts:

Can you give an example of a well-designed class in C#?

What are some common mistakes to avoid when designing classes?

How do I refactor a "GodObject" into smaller, focused classes?

Svep för att visa menyn