Question

In trying to centralize how items are added, or removed from my business entity classes, I have moved to the model where all lists are only exposed as ReadOnlyCollections and I provide Add and Remove methods to manipulate the objects in the list.

Here is an example:

public class Course
{
    public string Name{get; set;}
}

public class Student
{
    private List<Course>_courses = new List<Course>();
    public string Name{get; set;}
    public ReadOnlyCollection<Course> Courses {
        get{ return _courses.AsReadOnly();}
    }
    public void Add(Course course)
    {
        if (course != null && _courses.Count <= 3)
        {
            _courses.Add(course);
        }
    }
    public bool Remove(Course course)
    {
        bool removed = false;
        if (course != null && _courses.Count <= 3)
        {
            removed = _courses.Remove(course);
        }
        return removed;
    }
}

Part of my objective in doing the above is to not end up with an Anemic data-model (an anti-pattern) and also avoid having the logic that adds and removes courses all over the place.

Some background: the application I am working with is an Asp.net application, where the lists used to be exposed as a list previously, which resulted in all kinds of ways in which Courses were added to the Student (some places a check was made and others the check was not made).

But my question is: is the above a good idea?

Answer 1

Yes, this is a good approach, in my opinion you’re not doing anything than decorating your list, and its better than implementing your own IList (as you save many lines of code, even though you lose the more elegant way to iterate through your Course objects).

You may consider receiving a validation strategy object, as in the future you might have a new requirement, for ex: a new kind of student that can have more than 3 courses, etc