I just read an interesting critisim of some of the feature in ASP.NET “Whidbey“. I posted a reply that I wanted to capture in my own blog with some additional thoughts:
There were really two parts to the critisim: The first had to do with class naming and the author’s dislike of the class names we chose (such as Roles and MembershipUser). The author makes some good points about naming choices, i.e. why we chose Roles instead of groups and why we have a MembershipUser class instead of a User class. The roles vs. groups argument can fall either way, we chose to go with roles since the ASP.NET V1.X feature was called ‘Role based Security’. It would be a little confusing if we had instead called it ‘Group based security’. Secondly, why not call the MembershipUser object User. Initially we did, but there also happens to be another class ‘User’ that already exists. Had we called our Membership User ‘User’ a fully qualified type name would have been needed for any references to it — yuck!
The critisim, however, is interesting (and valid) because we had all the exact same discussions on the feature team <g> – we obviously reached different conclusions though. Someday maybe we can start publishing our design documents (Membership is about 70pp and Roles is about 60pp) where we capture some of these issues and in some cases, reasons for design changes.
There was also some feedback within the post about the overall object oriented design of the system. For example, why not cut features such as Membership into many sub-interfaces instead of having one large interface; or why have methods that all data stores can’t support, such as GetPassword() — side note, we’re moving to an abstract base class model in the beta.
In any implementation there is always a trade-off between functionality/usability and pure object-oriented design. This is a philisophical debate for how software should be built. There are two sides:
1. Pure object-oriented design – the design should be sufficiently complex as to allow/control for any changes to keep the design ‘pure’. For example, dividing the Membership functionality of ASP.NET into many smaller interfaces where each interface could control a specific set of behaviors, e.g. IValidateUser, IPasswordManagement, IUser, IEncryptRoutines, etc. The developer then chooses which interfaces are most appropriate for the task and only implements those. Positives: the software can be infinitly customized. Negatives: sheer complexity. The emphasis in this philosophy is on the developer writing the system, not the developer using the system.
2. Designing for usability – the design should focus on simplicity and usability. For example, in Membership rather than having many interfaces for expressing behaviors there is one interface. Rather than having complete control over all the APIs, APIs are added that all data providers may not support. Positives: the software can be customized with less code. Negatives: behaviors are not segmented in an oo manner. The emphasis in this philosophy is on the end-user, i.e. who is using it and what are their common tasks.
The obvious trade-offs here are complexitity vs. simplicity. I’ve personally maintained that the simpler and more understandable the software is the less bugs and support problems you will have and more people will use it because they can actually understand it! Furthermore, the pure object-oriented philosophy is somewhat elitist — it places emphasis on who builds the software not on who uses the software, i.e. only the person who built it trully understands how it works due to the complexity. Our goal is to provide a model to address the problems of the majority – who will never extend our base functionality while still allowig the more advanced developers to extend our design, hence the ‘provider design pattern’.
What are your thoughts and what philosophy do you apply to building software?
P.S., drop by and say hi if you are attending the Bay Area .NET User’s group tonight — I’ll be presenting on ASP.NET “Whidbey”.
