Classes and Objects

C# Classes and Objects

A class is a blueprint for creating objects, providing properties and methods to define behavior. An object is an instance of a class, encapsulating data and functionality.


Key Concepts of Classes and Objects

1. Class

A class is a user-defined reference type that acts as a blueprint for objects.

Syntax:

class ClassName {
    // Fields
    // Properties
    // Methods
    // Constructors
}

Example:

class Car {
    public string Brand; // Field
    public void Drive() { // Method
        Console.WriteLine($"{Brand} is driving.");
    }
}

2. Object

An object is an instance of a class that holds data and can invoke methods.

Syntax:

Example:


Components of Classes

1. Fields

Variables declared within a class to hold data.

Example:

2. Properties

Encapsulate fields with get and set for controlled access.

Example:

3. Methods

Functions inside a class that define behavior.

Example:

4. Constructors

Special methods to initialize objects.

Example:


Access Modifiers

Control access to class members.

Modifier

Description

Example

public

Accessible from anywhere.

public int Age;

private

Accessible only within the same class.

private int age;

protected

Accessible within the same class and derived classes.

protected int age;

internal

Accessible within the same assembly.

internal int age;


Example: Full Class Implementation


Summary

  • Class: Blueprint for creating objects, containing fields, properties, methods, and constructors.

  • Object: Instance of a class, encapsulating state and behavior.

  • Components: Include fields (data), properties (controlled access), methods (behavior), and constructors (initialization).

  • Access Modifiers: Control visibility and accessibility of members.

Classes and objects form the foundation of Object-Oriented Programming in C#, promoting modularity, reusability, and encapsulation.


Why Use Properties Instead of Fields?

Using properties instead of directly exposing fields in C# is a good practice due to the benefits of encapsulation, data validation, and flexibility. While fields are simple and straightforward, they lack the ability to control how data is accessed or modified.

1. Encapsulation and Control

  • Fields: Directly exposing fields makes it impossible to control how data is accessed or modified.

  • Properties: With get and set, you can control the logic for accessing or modifying a value.

Example:

Versus:


2. Data Validation

  • Fields: No way to validate data before setting it.

  • Properties: You can add logic to ensure data consistency.

Example:


3. Read-Only or Write-Only Access

  • Fields: Cannot restrict access for reading or writing.

  • Properties: Can make a property read-only (get only) or write-only (set only).

Example:


4. Automatic Properties

  • Simplify property declarations while still maintaining encapsulation.

Example:

This avoids the verbosity of manually implementing backing fields unless you need custom logic.


5. Future Flexibility

  • Fields: Once exposed, you cannot later add logic to control access without breaking the API.

  • Properties: Let you modify the internal logic (e.g., add validation, logging, or computed values) without changing the external interface.

Example:


When Should You Use Fields?

  • Fields are suitable for private members that are not meant to be accessed directly outside the class.

  • Use fields for constants (const) or read-only values (readonly) where properties would add unnecessary overhead.

Example:


Summary

Feature

Field

Property

Encapsulation

No control over access/modification.

Allows full control via get and set.

Data Validation

Not possible.

Can validate data before setting it.

Access Control

Always read-write.

Can be read-only or write-only.

Flexibility

No room for future changes.

Logic can evolve without breaking the interface.

Use Case

Internal/private constants.

Exposed data requiring control or validation.

In summary, use properties when exposing data to maintain control and flexibility. Fields are best kept private or used for fixed, internal values.

Last updated