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.

Not only does it do that, but the actual gist that you create is a full fledged Git repository, which means you have the ability to clone it , pull and push from it.

I also use a plug in for my blog that let’s me show individual files on any of my gists.

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

Not to worry. In the Self-Organizing stage your role turns to more of a Coach. You need to grow your team into learning new things, technologies or tools to help them in what they do. Inspire them to be passionate about their job. This is also the perfect stage to take those team members that you identified earlier as your potential leaders and really coach them into becoming leaders. If you do your job well enough, then they can do your job for you. This is not a bad thing. If they can do your job for you, that frees you up to help with other projects, or start new ones.

In reality, a team will never be able to sustain being in the Self-Organizing stage, though. Teams will cycle through stages. Usually it’s a circular pattern. It almost always happens because the scope of the project changes in some way. Maybe they need to learn a whole new technology stack. Maybe the project has taken a whole new direction and you need to develop completely new projects. If this happens don’t think it’s a sign that you or your team has done something wrong. It’s just a natural part of the team cycle. It should be easier for subsequent cycles. The more your team has experience going through the cycles, and gain experience with how they work inside each cycle, the easier it will be to ramp back up to Self-Organizing.

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.