SOLID Principles – Part 06 – Dependency Inversion Principle

Principle Classes that depend on other classes should depend on abstractions rather than concrete implementations. This makes the classes much more flexible to changing implementations. Scenario To demonstrate ISP I will continue using the E-Commerce example from the previous blog. A customer has an order which includes multiple order items. Given an order we calculate … More SOLID Principles – Part 06 – Dependency Inversion Principle

SOLID Principles – Part 05 – Interface Segregation Principle

Principle Functionality should be broken into specific interfaces rather than one all-purpose interface. This means clients are not be forced to depend upon methods that they do not use. Scenario To demonstrate ISP I will continue using the E-Commerce example from the previous blog. A customer has an order which includes multiple order items. Given … More SOLID Principles – Part 05 – Interface Segregation Principle

SOLID Principles – Part 04 – Liskov Substitution Principle

Principle This principle is an extension of the Open Close Principle and was first introduced by Barbara Liskov during a conference keynote speech. We need to ensure that new derived classes are extending the base classes without changing their behaviour. You should be able to replace a class with its base type without altering the … More SOLID Principles – Part 04 – Liskov Substitution Principle

SOLID Principles – Part 03 – Open Closed Principle

Principle A class, properties and methods should be open for extension but closed for modification. E.g. If we need to add new functionality to a class, it should be added using a derived class. Scenario To demonstrate OCP I will continue using the E-Commerce example from the previous blog. A customer has an order which … More SOLID Principles – Part 03 – Open Closed Principle

SOLID Principles – Part 02 – Single Responsibility Principle

Principle A class should only have a single responsibility. E.g. If it’s a logging class it should only do logging. If it’s a payments class it should only do payments, and so forth. A class should only have one reason to change. Scenario To demonstrate SRP I will use an E-Commerce example. A customer has … More SOLID Principles – Part 02 – Single Responsibility Principle

Unit Testing – C# – Part 06 – Building Out the Class 4

In this blog we will continue testing our Scorer class by adding some statistics. Get the Number of Strikes and Spares We need to keep track of the number of Strikes and Spares thrown in a game. Let’s write the tests. [Test] public void Check10SparesWereThrown() { for (int _bowl = 1; _bowl <= 10; _bowl++) … More Unit Testing – C# – Part 06 – Building Out the Class 4

Unit Testing – C# – Part 05 – Building Out the Class 3

In this blog we will continue testing our Scorer class by adding Spares and Strikes. Adding Spares Looking at the rules for spares. If we knock down 10 pins with 2 bowls, we add 10 plus the value of the next bowl. Here is our failing test. [Test] public void CalculateScoreWithSpares() { _scorer.FrameScore(0, 0); Assert.That(_scorer.Score, … More Unit Testing – C# – Part 05 – Building Out the Class 3

Unit Testing – C# – Part 04 – Building Out the Class 2

This is a continuation of the last blog where we continue to create tests and code for our Tenpin Bowling Scorer class. Refactoring If you look at the code below you will notice we are instantiating the Scorer class in each test. [TestFixture] public class Scorer_NUnit_Tests { [Test] public void ShouldReturnPlayersName() { var _player = … More Unit Testing – C# – Part 04 – Building Out the Class 2

Unit Testing – C# – Part 03 – Building Out the Class 1

In the last blog I discussed the project structure and the unit testing frameworks I will use. In this blog I will begin building out the class and tests based on our business requirements. Players Name I need to enter a player’s name and have the ability to get it. I always start our defining … More Unit Testing – C# – Part 03 – Building Out the Class 1