How to model table and column objects and their relation

Question

I'm working on a small application where I need to model tables and columns from a relational DB.

I've been reading some material on nested classes, which is recommended to be used sparsely. However I'm thinking that this might be such a scenario.

I wish to implement these objects as follow:
1. Table contains List<Column>
2. Preferably it is not possible to create a Column object unless you use a method on the Table object (eg Table.addColumn()).
3. Existing columns should be available outside the Table object in such a way that you may reference the column and it's public methods and properties from anywhere in your code.
4. Column must know of the Table object it belongs to.
5. Both Columnand Table implements IEquatable and maybe IEnumerable.

The options I see are:
1. Use nested classes where Column is enclosed in Table, protecting the constructor of Column from being called by external code.
2. Implement Column and Table as regular classes, injecting the Table object into the constructor of Column. This could be handled by a method in the Table object taking care of the "injection" and returning the resulting Columnobject. This does however, expose the constructor of Column to the rest of the implementation.
3. Create a separate DLL combined with the Internal access modifier to protect the Column constructor.

What would you say is the best solution here?

Cheers

Answer 1

I would start by providing the right API to add columns to the table. If tableObject.addColumn (...) is appropriate then build that.

You don't have to allow arbitrary column objects to be added to tables: you can control every aspect of the creation of an appropriate Column object via the Table addColumn instance method implementations. These methods can take Column creation parameters and create and attach the Column themselves.

Therefore, I wouldn't worry about preventing people from creating a Column object. If someone creates one independently, they won't be able to use it for anything Table related, so it is harmless. There's a lot arbitrary objects people can create (an array of int, ...) that are so harmless to your code, there's no point in preventing them from trying to do so.

---

On the other hand, you could create an abstract Column class (or interface) and then subclass that (say as TableColumn), and nest that within Table. This way you separate the Column API people will need to see when enumerating the columns, without providing a specific constructor. The TableColumn nested class can have any private linkages and constructors it needs.

You still can't necessarily prevent someone from subclassing the abstract Column on their own and providing a constructor to create instances, but so what, it is harmless to your Table.