One of the key design decisions when writing any code is what level of access you should give each component. In general, my rule of thumb is “As little access as possible.” What this means is that I don’t want to make any class public that doesn’t need to be, and I don’t want to make any members public that are implementation details. In NoRM, we’ve tried to be judicious about what makes it into the Public API, there’s a number of reasons for this:KISS, presenting 20 classes to the user when there are only a handful of relevant ones makes for a confusing introduction. NoRM effectively has 4 major and immediately relevant classes: “Mongo”,”MongoDatabase”,”MongoCollection”,”MongoConfiguration”, telling the user about the other X classes that make everything happen is an over-share. I don’t like over-shares.
Making things public that shouldn’t be increases the likelihood that people can break your code in ways that you can’t conceive of. If one controls how code is accessed, there’s a whole class of issues that just cannot happen.
I recently had a conversation with a developer who has more experience, both in industry, and in Open Source than I do. I respect him. His stance was that when we’re talking about Open Source software specifically, the library should not place restrictions on what code a consumer can execute. I fundamentally disagree with that stance. Here’s why:A responsible project will understand that the software they’re helping to form will be used by other people. By making everything public, you’re implicitly giving license to consumers to use it however they wish, likely in scenarios that you couldn’t plan for. This may sound good, but when the class they use is for mainly infrastructure purposes and the project maintainers want to implement the feature in a different way, they’ll likely break the consumer.
The code is Free and Open, if a consumer really must use some class that the project maintainers marked as private/protected/internal, then it’s a simple matter of going in and marking it public. I believe this has the added benefit causing people to pause and ask the question: “Why was this marked in such a way as to prevent access to me — maybe the designers had a good reason?”
A corollary to the last point is that if there is a true roadblock in how someone wants to use the existing classes and codebase, we want to hear from them in the google groups. We want to know how people are using the library. We want to add the features they need. I should note that I don’t think we’re infallible on this stuff, there are a number of features in NoRM that I think are wonderful, but had it been me alone working on the project, those features wouldn’t have been implemented. The point is, try to contribute your ideas and features of NoRM, don’t roll your own, and then get broken the next time there’s a release. What do you think?