Implementing equality of derived reference types by overriding the == operator with C# .NET

In this post we saw one solution to override the == operator for a reference type to implement equality checking. Here’s a reminder of the Person class:

public class Person
{
	public int Id { get; set; }
	public string Name { get; set; }
	public int Age { get; set; }

	public static bool operator ==(Person personOne, Person personTwo)
	{
		return personOne.Id == personTwo.Id;
	}

	public static bool operator !=(Person personOne, Person personTwo)
	{
		return personOne.Id != personTwo.Id;
	}

        public override int GetHashCode()
	{
		return Id;
	}
}

Read more of this post

Implementing the IEquatable of T interface for object equality in a derived class with C# .NET

In this post we saw how to implement the IEquatable of T interface for a simple Person class. We based our equality logic on the Id property of the object. We implemented the IEquatable.Equals method and also overrode the Object.Equals and GetHashCode methods.

In this post we’ll see how you might go about extending that logic in derived classes. For that purpose we’ll go with another object:

Read more of this post

SOLID principles in .NET revisited part 8: clean-up

Introduction

In the previous post we covered letter ‘D’, i.e. the Dependency Inversion Principle among the SOLID principles.
A class can have a number of dependencies in order to perform its functions properly. Applying DIP will open an entry point for the clients to supply their own implementations for those dependencies when they call upon that class. The class in turn can remove all responsibility of creating concrete implementations for its abstract dependencies. The result will be loosely coupled code where a class won’t be tightly coupled to concrete services.

In this post we’ll only clean up a couple of remaining issues in the code.

Remove “virtual”

In the post on OCP we mentioned that the “virtual” keyword provided an extensibility point for a class. However, since then we know that abstractions provide a much better alternative. Hence we don’t have to make our methods virtual any more:

Read more of this post

How to declare natural ordering by overriding the comparison operators in C# .NET

In this post we saw one way to declare natural ordering for a custom class by implementing the generic IComparable of T interface. In this post we’ll look at how to achieve the same by overriding the 4 comparison operators:

<
>
<=
>=

Read more of this post

SOLID principles in .NET revisited part 7: the Dependency Inversion Principle

Introduction

In the previous post we saw the definition of the Interface Segregation Principle. We applied it to a problematic case where a class could not fully implement the IAuthorizationService interface. We then broke up the interface into two parts so that they became more specialised. A consequence of ISP is often a large number of small, very specialised interfaces of 1 or maybe 2 methods. Large, monolithic interfaces are to be avoided as it will be more difficult to find concrete classes that can meaningfully implement all interface methods.

We’ve reached the last letter in the SOLID acronym, i.e. ‘D’ which stands for the Dependency Inversion Principle.

Read more of this post

Combinable enumerations in C# .NET: numeric values of large enums

In this post we saw how to build an enumeration that can be combined using the bitwise OR, i.e. | operator:

var frontEndProgrammer = SoftwarePositions.Programmer | SoftwarePositions.FrontEnd;

We saw that enumeration values must be set in powers of two:

Read more of this post

Using the StringComparer class for string equality with C# .NET

In this post we saw how to use the generic IEqualityComparer of T interface to indicate equality for our custom types. If you need a similar comparer for strings then there’s a ready-made static class called StringComparer which can construct string comparers for you.

The StringComparer class provides comparers for the common string comparison scenarios: ordinal, locale specific and invariant culture comparisons. This is a good MSDN article on the differences between these.

Read more of this post

SOLID principles in .NET revisited part 6: the Interface Segregation Principle

Introduction

In the previous post we continued to discuss the Liskov Substitution Principle. We saw a subtle example of breaking LSP by trying to force an object to implement an interface even though not all methods of the interface made sense for it. The client object, i.e. OnDemandAgentService cannot consume all implementations of IAuthorizationService without fully being able to carry out its tasks.

A possible solution comes in the form of letter ‘I’ in SOLID, which stands for the Interface Segregation Principle (ISP). ISP states that clients should not be forced to depend on interfaces and methods they do not use. Applying ISP correctly will result in a lot of small interfaces instead of handful of large ones with lots of methods. The more methods to an interface has the more likely it is that an implementation will not be able to fulfil all parts of the contract. The IAuthorizationService only has 2 methods and we immediately found an example where a class, the AuthorizationService only could implement one of them.

Read more of this post

Implementing equality of reference types by overriding the == operator with C# .NET

In this post we saw how to implement the generic IEquatable interface to make two custom objects equatable using the static Equals method.

You’re probably aware of the equality operator ‘==’ in C#. Let’s see what happens if you try to use it for a custom object:

public class Person
{
	public int Id { get; set; }
	public string Name { get; set; }
	public int Age { get; set; }
}

Read more of this post

SOLID principles in .NET revisited part 5: the Liskov Substitution Principle 2

Introduction

In the previous post we looked at letter ‘L’ in SOLID, i.e. the Liskov Substitution Principle. We saw how adhering to the LSP helps remove implementation-specific details from a client class that consumes those implementations. The client class will be able to consume the services of an abstraction without worrying about the actual implementation of the abstraction. The goal of LSP is that any implementation of an abstraction will work seamlessly within the consuming class.

We looked at the following cases that can indicate a violation of LSP:

  • switch or if-else blocks checking for the value of an enumeration
  • Code blocks that check the actual type of an abstraction to branch logic. This can be coupled with downcasting the abstraction to a concrete implementation type
  • Blocks with magic strings that check for a value in some string parameter and branch logic accordingly

There’s at least one more indicator which we haven’t seen so far. I decided to devote a separate article to that case as it brings us closer to the next constituent of SOLID, i.e. the Interface Segregation Principle.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

ARCHIVED: Bite-size insight on Cyber Security for the not too technical.