A Day is pretty simple. It has the DateTime that says what actual day it belongs to. It also has a list of Events that belong to it. A Day can also indicate whether or not it’s available for reading, or if it has events. This is important because if a day is available, then the UI needs to let the user select that Day, and if it has events, then the day should show those events in the UI.

public class Day
{
    public DateTime Date { get; set; }

    private IList<Event> Events { get; set; }

    public Day()
    {
        Events = new List<Event>();
    }

    public bool HasEvents()
    {
        return Events.Count > 0;
    }

    public void AddEvent(Event eventForDay)
    {
        Events.Add(eventForDay);
    }

    public IList<Event> GetEvents()
    {
        return Events;
    }

    public string GetReadingAvailability()
    {
        return IsAvailable() ? "date_is_available" : 
          HasEvents() ? "date_has_event" : "");
    }

    private bool IsAvailable()
    {
        return !HasEvents() && IsDayAvailableForReading();
    }

    private bool IsDayAvailableForReading()
    {
        return IsDayAvailableForReading(Date);
    }

    public static bool IsDayAvailableForReading(DateTime dateTime)
    {
        return new AvailabilityChecker()
          .IsDayAvailableForReading(dateTime);
    }

    public string GetReadableValue()
    {
        return Date.ToString("MMMM dd, yyyy");
    }
}

This concludes the implementation of all the pieces necessary to build the ViewModel. The View itself could be built on any technology stack to show UI appropriate to the rules we outlined so far, which is the ultimate goal of having our ViewModel separated from the View itself.

This does not, however, tell us what our business rules are, or how their implemented, which is the next part of the series: the Model.

When you first look at the month implementation, you might think that adding days to weeks is a simple matter of adding DateTime’s, but what’s happening behind the scenes is just a little bit more complicated. Why? Well, we need to track what events belong to what days, so in order to do that we can’t just use a simple DateTime, we need something just a little bit more complicated.

My Week looks like this:

public class Week
{
    public Week()
    {
        Days = new List<Day>();
    }

    protected IList<Day> Days { get; set; }

    public IEnumerable<Day> GetDays()
    {
        return Days;
    }

    public void Add(DateTime day)
    {
        if (!Days.Where(x => x.Date == day.Date).Any())
            Days.Add(new Day { Date = day });
    }

    public bool IsMissingDays()
    {
        return Days.OrderBy(x => x.Date)
          .First().Date.DayOfWeek != Calendar.GetStartDay();
    }

    public bool IsMissingTrailingDays()
    {
        return Days.OrderBy(x => x.Date)
          .First().Date.DayOfWeek != Calendar.GetLastDay();
    }

    public int GetMissingNumberOfDays()
    {
        var missingDays = 0;

        var day = Days.OrderBy(x => x.Date).First().Date;
        
        do
        {
            day = day.AddDays(-1);
            missingDays++;
        } while (day.DayOfWeek != Calendar.GetStartDay());

        return missingDays;
    }

    public int GetMissingNumberOfTrailingDays()
    {
        var missingDays = 0;

        var day = Days.OrderBy(x => x.Date).Last().Date;

        do
        {
            day = day.AddDays(1);
            missingDays++;
        } while (day.DayOfWeek != Calendar.GetLastDay());

        return missingDays;
    }
}

When adding days to the week, I accept a DateTime and then build a list of Days into the Week. Later on, the calendar will add Events to these Days.

So building a Month is all about one thing: building it’s weeks. The only other thing I need from a month is the ability to get it’s name (i.e. January, February, etc.). My implementation of this looks something like this:

public class Month
{
  private DateTime FirstDayOfMonth { get; set; }
  
  private IList<Week> Weeks { get; set; }

  public Month(int monthValue)
  {
      FirstDayOfMonth = new DateTime(DateTime.Now.Year, monthValue, 1);
      
      Weeks = new List<Week>();

      BuildMonth();
  }

  private void BuildMonth()
  {
      var startDay = Calendar.GetStartDay();

      var week = new Week();

      var day = FirstDayOfMonth;
      
      do
      {
          if (WeekHasEnded(day, startDay) && WeekIsNotEmpty(week))
          {
              Weeks.Add(week);
              week = new Week();
          }

          week.Add(day);
          
          day = GetNextDay(day);

      } while (day.Month == FirstDayOfMonth.Month);

      Weeks.Add(week);
  }

  private bool WeekIsNotEmpty(Week week)
  {
      return week.GetDays().Count() > 0;
  }

  private bool WeekHasEnded(DateTime day, DayOfWeek startDay)
  {
      return day.DayOfWeek == startDay;
  }

  private DateTime GetNextDay(DateTime day)
  {
      return day.AddDays(1);
  }

  public DayOfWeek GetFirstDayOfMonth()
  {
      return FirstDayOfMonth.DayOfWeek;
  }

  public IList<Week> GetWeeks()
  {
      return Weeks;
  }
  
  public string GetMonthName()
  {
      return string.Format("{0:MMMM}", FirstDayOfMonth);
  }
}

So my Calendar looks like this:

public class Calendar
{
  public Calendar()
  {
      Months = new Dictionary<int, Month> 
        {{DateTime.Today.Month, new Month(DateTime.Today.Month)}};
  }

  protected IDictionary<int, Month> Months { get; set; }

  public Month GetCurrentMonth()
  {
      return GetMonth(DateTime.Today.Month);
  }

  public Month GetNextMonth()
  {
      return GetMonth(DateTime.Today.Month + 1);
  }

  public Month GetMonth(string month)
  {
      return GetMonth(
        DateTime.ParseExact(
          month, "MMMM", CultureInfo.CurrentCulture)
        .Month);
  }

  public Month GetMonth(int monthValue)
  {
      if (!Months.ContainsKey(monthValue))
          Months.Add(monthValue, new Month(monthValue));

      return Months[monthValue];
  }

  public static DayOfWeek GetStartDay()
  {
      return DayOfWeek.Monday;
  }

  public static DayOfWeek GetLastDay()
  {
      return DayOfWeek.Sunday;
  }

  public void IncludeEvents(IList<Event> events)
  {
      foreach (var @event in events)
      {
          IncludeEvent(@event);
      }
  }

  private void IncludeEvent(Event eventToInclude)
  {
      var allDaysQuery = from week in GetMonth(
          eventToInclude.Day.Month)
            .GetWeeks()
        from day in week.GetDays()
        select day;

      var filteredDays = from day in allDaysQuery
                         where day.Date == eventToInclude.Day.Date
                         select day;

      var dayToAddEventTo = filteredDays.First();

      dayToAddEventTo.AddEvent(eventToInclude);
  }
}

The Calendar is really only concerned with one thing: showing events that belong to it. In order to accomplish this goal, the Calendar must be able to include events into the months on the Calendar.

In order to do this, the Calendar has to be able to build months, and then include the events into the days of those months. All of this logic takes place in the IncludeEvent method, which utilizes quite a few other classes to accomplish this.

In the next post, we’ll take a look at the other classes we used in the ViewModel to accommodate our Calendar

The underlying problem here is simple, actually. The real issue stems from the fact that the Ellipse (and by proxy the Circle) was designed as a Hybrid object. As I’ve said before, and others before me, Hybrid objects are evil. To fix this, we need to either make these classes Data Structures, or make them Objects. Since the whole point of the code is to calculate the area, I say we have to make them Objects.

To do that, I made the following changes to Ellipse:

public class Ellipse
{
  protected virtual int MajorAxis { get; set; }
  protected virtual int MinorAxis { get; set; }

  public Ellipse(int majorAxis, int minorAxis)
  {
    MajorAxis = majorAxis;
    MinorAxis = minorAxis;
  }
  
  public virtual double CalculateArea()
  {
    return Math.Pi * MajorAxis * MinorAxis;
  }
}

Notice how MajorAxis and MinorAxis can still be extended via a subclass if need be, but they are only accessible from sub classes now, not from the outside world. This removes the class’s Data Structure flavor and make it’s a pure Object. It also has a great side benefit. Now a user can only create an Ellipse by supplying the major and minor values when the Ellipse is created. This logically makes sense because an Ellipse can’t exist without it’s major and minor axes.

So how does this effect the Circle now? This is how I changed the Circle:

public class Circle: Ellipse
{
  public Circle(int radius)
  {
    MajorAxis = radius;
    MinorAxis = radius;
  }  
}

A lot of code has been removed. It almost seems like I’ve cheated somewhere, doesn’t it? Well, now that Ellipse is acting as a pure Object, the only thing Circle needs to do is to explain why it’s “special”. As we noted before, a Circle is special because it has a Radius. In other words, it’s major and minor axes have the same length. So the Circle class simply explains that relationship, and you’re done. The area calculation doesn’t need to be modified because the real difference was showing how the radius is related to the major and minor axes.

Now the runner is forced to use the classes in a way that prevents them from being used in inappropriate ways:

public class Runner
{
  public void UsingEllipsesAndCircles()
  {
    var ellipse = new Ellipse(10, 5);    
    
    var areaOfEllipse = ellipse.CalculateArea();
    
    var circle = new Circle(4);
        
    var areaForCircle = circle.CalculateArea();    
  }
}

So first things first, let’s go over some math and set up the problem space.

You have an Ellipse. You have a Circle. A Circle is a special kind of Ellipse. Specifically, an Ellipse has a major axis and a minor axis, and a Circle is special because it’s major and minor axis are equivalent in their length.

So when a developer initially goes to model these objects, you typically would see something like this:

public class Ellipse
{
  public virtual int MajorAxis { get; set; }
  public virtual int MinorAxis { get; set; }

  public virtual double CalculateArea()
  {
    return Math.Pi * MajorAxis * MinorAxis;
  }
}

I see this implementation a lot. When asked how this supports SOLID principles, I get the following a lot of the time:

It supports OCP because I can override any of the properties or the methods. Ok good.

It supports SRP because the class is only responsible for knowing things about Ellipse. Ok good.

And there are some other ones, but then we veer into trying to extend this model with the special Circle, and that’s where things really start to break down. I’ve seen a lot of variations about how this goes down, but I’m going to summarize all of them with this definition:

public class Circle: Ellipse
{
  public int Radius { get; set; }
  
  public override double CalculateArea()
  {
    return Math.Pi * Radius * Radius
  }
}

What happens here is a new property is introduced so that the users know that Circles are special because they have a Radius. Then when we calculate the Area, we override the function that calculates the area and we use the radius instead.

So someone would use it like this:

public class Runner
{
  public void UsingEllipsesAndCircles()
  {
    var ellipse = new Ellipse();
    ellipse.MajorAxis = 10;
    ellipse.MinorAxis = 5;
    
    var areaOfEllipse = ellipse.CalculateArea();
    
    var circle = new Circle();
    circle.Radius = 4;
    
    var areaForCircle = circle.CalculateArea();    
  }
}

So what’s the problem with this? Think about it an tomorrow I’ll post my proposed solution.

So before we get to any code I’d first like to explain how I see the Model and ViewModel shaping conceptually. The domain is basically as follows:

The system needs to be able to allow users to sign up as Readers for a particular day. The time that they are going to read is always the same, it’s 10 AM for an hour. The days that a user can sign up to be a Reader are specific. For the most part, the days are Monday, Tuesday, Thursday and Friday, but there are also some other rules like the week of Thanksgiving there won’t be any readings. Currently, this is being done by the teacher where she prints out a Reading Calendar that has the days for reading highlighted. What needs to be done is basically the same thing. We need to make a calendar that shows everyone all the days that are eligible for signing up, and let them sign up for those days. It also needs to show them the days that have already been signed up, and show the Reader for that day.

Ok, so that’s the basics. Now, the question here is how is the Model and ViewModel broken down?

To illustrate this it would probably be better to start with the user experience, and hence the ViewModel. So the user will be presented with a Calendar, and they should be able to see Events that show up on the calendar, like they’re most likely already used to. These Events will show who’s signed up. Now, the user also needs to be able to Sign Up. That’s the extent of the first version of the ViewModel I came up with. We have a Calendar, Events, and a SignUp.

Now, onto the Model. When the user signs up, they’re telling the system that they want to be a Reader for a particular day. Once they become a Reader then the system shouldn’t allow anyone else sign up on that day. So that’s really the Model. We have a bunch of Readers and some logic that keeps you from signing up multiple Readers on the same day.

So how does the Model and ViewModel relate? Well, there are two key relationships here. First, when a user signs up, we’ll have to map the SignUp over to a Reader. Second, when we show the user a calendar, we need to get all the Readers for those days, and map the Readers over to Events which the Calendar knows how to show.

Notice the last thing I said there. The Calendar knows how to show Events, but it doesn’t know anything about Readers. The implications here allow your system to be truly decoupled and makes it much more maintainable.

So how did I implement this? I’ll show you on my next post.

So why is SRP so important? I guess it’s all in it’s definition. A class or file should only have one reason to change. If it has more than one reason to change, then your code will become brittle and difficult to maintain. The problem with SRP is how difficult it is to follow. SRP feels a lot more like an art than a science at times. You get into situations where you’re not sure whether or not a class is only doing one thing, and if you need to further abstract away code into separate classes.

As a simple example, let’s say you have a Car that needs to be able to start it’s Engine

public class Car
{
  public void Start()
  {
    Engine.StartPistons();
    Engine.InjectOxygen();
    Engine.InjectFuel();
  }
}

This Car knows way too much about it’s Engine. If the Engine’s starting sequence ever needs to be changed, you have to actually go into the Car class to change it! That just doesn’t make any sense. What we should be doing instead is abstracting away that functionality inside the Engine class and allowing the Car to simply start the Engine when it needs to.

public class Engine
{
  public void Start()
  {
    StartPistons();
    InjectOxygen();
    InjectFuel();
  }
 
  private void StartPistons() { ... }
  private void InjectOxygen() { ... }
  private void InjectFuel() { ... }
}

This Engine prevents other classes from using it improperly. Part of learning how to effectively use SRP is to identify when you’re exposing too much of a class. In the previous Engine the Car was calling each function inside the Engine. This better designed Engine hides this functionality from outsiders, so the Car now has no choice but to use only the start method.

The Car now has to look something like this

public class Car
{
  public void Start()
  {
    Engine.Start();
  }
}

This is a class structure that utilizes SRP.

Want more info? Check out this dime cast.

The best way to explain this principle would probably be an example.
Let’s say you have a car like this

public class Car
{
    public Car()
    {
        Engine = new FourCylinderEngine();
    }    
    
    private FourCylinderEngine Engine { get; set; }
    
    public void Start()
    {
        Engine.Start();        
    }
}

Notice the engine that belongs to the car. First of all, the car is actually creating the engine. This means that the car is tightly coupled to the engine it’s creating. Secondly, this creates a concrete coupling on the car to a specific kind of engine, the FourCylinderEngine.

A better solution would be to use Dependency Inversion. You should depend on an interface instead of a concrete class. Back in our example, our FoudCyclinderEngine looks like this

public class FourCylinderEngine : Engine
{
    public void Start()
    {
        StartRotatingPistonsOneAndThreeAtPhase(0.Degrees);
        StartRotatingPistonsTwoAndFourAtPhase(90.Degrees);
    }
}

Notice how it implements Engine. That’s the interface our Car should be using. There’s one additional problem, though. Right now the Car is creating it’s Engine, but you can’t instantiate an interface, so what do you do? That’s the key to Dependency Inversion. You’re saying,

a Car does not depend on knowing about how to create an Engine

It just uses it. So the new Car class looks like this

public class Car
{
    public Car(Engine engine)
    {
        Engine = engine;
    }    

    private Engine Engine { get; set; }

    public void Start()
    {
        Engine.Start();        
    }
}

So how does the engine get created? Obviously something is passing in the engine to the Car, but what? You need a new class. Maybe a CarManufacturer or something, which is responsible for manufacturing cars. Part of that responsibility would be putting an engine in a car.

Want more info? Check out this dime cast.

I think a prime example of an interface that violates this principle would be MembershipProvider class which is commonly used in ASP.NET applications. Granted, this isn’t technically an interface (it’s actually an abstract class), but it demonstrates the principle perfectly. If you’ve ever tried to make your own custom membership provider, and you’ve had to implement this beast, you already know the pain involved. There are a ridiculous number of methods involved with this class. There are so many, actually, that the best practice inside many .NET circles has been to simply throw a NotImplementedException for any methods you don’t want to spend the time implementing.

The solution would be to actually break up this abstract class into many smaller classes, so the developer could extend the parts that needs to be customized, and leave the rest alone.

Want more info? Check out this dime cast.