DEV Community: Ahmed Elmehalawi

Different ways to implement Shallow Copy in C#

Ahmed Elmehalawi — Fri, 11 Oct 2024 12:09:20 +0000

In C#, reference types are objects that are stored in the heap. When these types are assigned or passed, they share the same memory location. This behavior can lead to unintended consequences, as modifying one reference affects all other references pointing to the same object. In certain scenarios, it may be necessary to create a separate value copy from a reference type to avoid such side effects.

Consider the following class, which contains several value-type properties:

    public class Employee
    {
        public string FirstName { get; private set; }
        public string LastName { get; private set; }
        public string Title { get; private set; }


        public Employee(string firstName, string lastName, string title)
        {
            FirstName = firstName;
            LastName = lastName;
            Title = title;
        }
        public void UpdateName(string firstName, string lastName)
        {
            FirstName = firstName;
            LastName = lastName;
        }

        public void UpdateTitle(string title)
        {
            Title = title;
        }
    }

Suppose we create an instance of the Employee class:
Employee employeeInfo = new Employee("Ahmed", "Elmehalawi", "Software Engineer");

If we then create another Employee object by copying the employeeInfo data:
Employee copiedEmployeeInfo = employeeInfo;

Any changes made to employeeInfo will be reflected in copiedEmployeeInfo. For example, updating the title using the UpdateTitle method:
employeeInfo.UpdateTitle("Project Manager")

This update will change the title to "Project Manager" for both employeeInfo and copiedEmployeeInfo, as both variables reference the same memory location on the heap.
However, if the intention is to create a copy of the object rather than share the same reference, we need to perform a shallow copy. A shallow copy creates a new object but copies the original object’s properties, ensuring that changes made to one do not affect the other.

Ways to implement Shallow Copy in C#:

1. MemberwiseClone
The MemberwiseClone method creates a shallow copy of the object:

public Employee ShallowCopy()
{
    return (Employee)this.MemberwiseClone();
}

Usage:-
Employee copiedEmployeeInfo = employeeInfo.ShallowCopy();
In this case, any changes made to one instance will not reflect on the other.

2. ICloneable interface
Implementing the Clone method using the ICloneable interface, which also utilizes MemberwiseClone:

public object Clone()
{
    return (Employee)this.MemberwiseClone();
}

3. Copy Constructor
A copy constructor explicitly creates a new instance by copying the values of the original object's properties:

public Employee(Employee employee)
{
    FirstName = employee.FirstName;
    LastName = employee.LastName;
    Title = employee.Title;
}

Usage:
Employee copiedEmployeeInfo = new Employee(employeeInfo);

4. JSON Serialization and Deserialization
Another approach is to use JSON serialization and deserialization to create a copy:

Employee copiedEmployeeInfo = JsonConvert.DeserializeObject<Employee>(JsonConvert.SerializeObject(employeeInfo));

5. Manual Property Copying
You can manually create a new object and assign values from the original object’s properties:

Employee copiedEmployeeInfo = new Employee(employeeInfo.FirstName, employeeInfo.LastName, employeeInfo.Title);

API Testing using .http Files in .NET

Ahmed Elmehalawi — Sat, 28 Sep 2024 10:50:52 +0000

In .NET 8, a new type of file, the .http file, has been introduced in API projects. The purpose of this file is to simplify API testing directly by writing and using simple HTTP commands.

The .http file is a plain text file that contains HTTP commands such as GET, POST, PUT, DELETE, and other requests used in APIs. Instead of relying on external tools like Postman or cURL, you can write your requests inside this file and run them directly from within Visual Studio or VS Code.
The main goal is to provide a simple and fast environment to test the APIs you're working on. Instead of switching to external tools for sending requests, you can handle everything inside the IDE. This also helps dev teams share a set of ready-made requests for testing purposes.

The file is quite simple and contains multiple requests in a specific format.
For example:

GET https://localhost:5000/api/products
###
POST https://localhost:5000/api/products
Content-Type: application/json
{
 "name": "Product X",
 "price": 100
}

One of the great features of .http files is that you can select which environment to run them in. For example, you might have an API running in different environments like Development and Production.

You can create an .env file that contains different settings for each environment:

{
 "dev": {
 "HostAddress": "https://localhost:5000"
 },
 "remote": {
 "HostAddress": "https://api.app.com"
 }
}

Then, use these variables inside the .http file:
GET {{HostAddress}}/api/products

Covering Index

Ahmed Elmehalawi — Sun, 18 Aug 2024 22:40:56 +0000

One of the beautiful concepts in databases is the Covering Index, which plays a significant role in improving query performance.
Simply put, this index contains all the columns needed in a query without having to perform a lookup inside the data table to fetch the required columns.

As we know, indexes enable the DBMS to access data more quickly, and indexes can be either clustered or non-clustered.

Each table has one clustered index, and the clustered index represents the physical order of the records. So, if we have a table named Student containing the following columns: Id, FirstName, LastName, Email, GPA, and our clustered index is on the primary key (which is Id), when we write a query to retrieve all the columns from Student where Id = 287, the clustered index will be used to reach that record and return the data.

On the other hand, a non-clustered index is stored separately from the table data and contains the columns I specify, along with either the clustered index key (if it exists) or the location of the row in the heap data pages (if the table doesn't have a clustered index).

So, if I create a non-clustered index on GPA, it will store GPA sorted in ascending order along with the clustered index key, which in our case is the Student Id.

If I need to retrieve all the columns from the table where the records match the condition GPA > 2.8, the query will first access the non-clustered index to get the IDs of the students whose GPA is greater than 2.8. Then it will use the original IDs to perform a key lookup to retrieve the column values.

This approach is much more performant than scanning every record in the original table, checking the GPA, and then retrieving the data.

However, it still involves two steps: first, fetching the matched records using the non-clustered index and then going back to the table to get the data.

Is there a way to fetch the data without going back to the table?

The answer is yes, and that's where the Covering Index comes in.
It's called a Covering Index because it covers the query's select columns that are needed.
Essentially, it's a non-clustered index with all the columns required for the query added to it, so it doesn't have to go back to the data table for a lookup. The data is already available within the index itself. Additionally, we can include the columns we need in the query without making them key columns in our non-clustered index.

#sql
#databases
#covering_index
#indexes
#clustered_index
#non_clustered_index
#development