You Vote: Do We Need More Namespaces?

Aspose.Words Product Family
1

At the moment the Aspose.Words namespace consists of approximately 130 public members. About 70 of them are classes, the rest are enumerations.

I think it is quite a big namespace. It is comparable to some of the big namespaces in .NET such as System.Data for example. While I don't see we will have much more new public classes in the future, there will be some for sure. For example classes and enums for dealing with custom tab stops and list formatting. It could take the number of public members in Aspose.Words to 160 or more.

Do you think 160 members in a namespace is too much and we should split the Aspose.Words namespace into a few smaller namespaces to make the API friendlier?

We already have some other namespaces beside Aspose.Words:

  • The mail merge related classes were in the Aspose.Words namespace, but moved out to Aspose.Words.Reporting in V3.0. There will be more classes to deal with reporting in the future. I think moving mail merge to the Aspose.Words.Reporting was a good thing.
  • The viewer classes fit neatly in Aspose.Words.Viewer and they will stay there.
  • The new classes for working with shapes and drawings will probably go to the new Aspose.Words.Graphics namespace.

Any ideas for new smaller namespaces?

  • Aspose.Words.Tables could contain classes and enums related to tables. Table, Row, Cell etc, around 10 members in total.
  • Aspose.Words.Fields could contain classes and enums related to fields and form fields, around 10 members.

2

Sounds like a good way to separate/divide the code. I like the Graphics, Tables, and Fields namespace ideas.

3

Allthough it sounds like a good idea to have a the namespaces split, in the end fot the programmer it does not make much difference because he/she will add the namespaces at the top of the code file and will just have e few more lines there.

Furthermore, this will require all developers to make code changes which are totally unnecessary, because, as you point out, there will not be a great expansion of classes in the future....

My vote: no.

Alex

4

Its about 8 months since I posted. The question is still hot.

During this time we added public types to deal with custom tab stops (about 5) and lists (about 8) into the Aspose.Words namespace.

We've also developed a whole new set of classes to deal with drawing objects and created a new Aspose.Words.Drawing namespace for it (about 30 members now).

Because some public types actually migrated from Aspose.Words to Aspose.Words.Drawing, the total number of public types in the Aspose.Words.Namespace remained about the same. I can count 125 at the moment and I still think it is a bit too much.

Whenever a user wants to accomplish a certain task, he should basically see only the classes and enums he needs most. I think the Aspose.Words namespace should include only the most frequently used types. For example Document, DocumentBuilder, Paragraph, Run, Font, ParagraphFormat and so on - there is no question they all should sit in the single Aspose.Words namespace.

But a lot of public types in Aspose.Words must be used pretty seldom, for example LineNumberRestartMode, Comment, Footnote, ChapterPageSeparator, NotChangedEventArgs.

There are many other types which are hard to tell whether they are used often or not without hard usability data. They should probably stay where they are.

Apart from making no changes and keeping the Aspose.Words big 130 public members namespace, we are considering several options:

  • Create namespaces by "functionality". Rough examples are: Aspose.Words.Fields, Aspose.Words.Tables, Aspose.Words.Lists and so on.
  • Create namespaces by "frequency of use". For example Aspose.Words and Aspose.Words.Advanced (or Aspose.Words.Specialized).

Much of .NET Framework seems to be built with namespaces by "functionality" or "technology". But from what I gather, there is an interesting guideline that suggests designing namespaces in such a way they help users to be productive and separate frquently used classes for simple scenarios from advanced ones.

If we create Aspose.Words.Tables, Aspose.Words.Lists etc, then the namespaces will be pretty small (8-12 public types) and when you code, you will end up using most of the namespaces for many of your tasks. For example, if you are programmatically building a document, you would end up using table classes, list classes, document classes and so on and you will have to pull them all from different namespaces. I think it is yuck.

On the other hand, if we create Aspose.Words and Aspose.Words.Advanced, then 90% of the time you will just have to deal with classes from Aspose.Words (my estimate the number of public types will come down to 85). Only if you want to do some "advanced" thing, you will need to include classes from Aspose.Words.Advanced (or Aspose.Words.Specialized or whatever the name is). There are problems with this approach too. The main problem is that there is no hard and fast rule to decide which class should go into which namespace and the user will have no idea where to expect to find a particular type. Also, it will "conflict" with already existing "by-technology" namespaces Aspose.Words.Drawing and Aspose.Words.Reporting.

Basically, I don't want a single huge namespace because I don't think it is right for the users. But I also don't want too many small namespaces because you will end up using them all everytime. And the problem is I don't know how to divide the huge Aspose.Words namespace. What is the right size for a namespace? My gut geeling the maximum is around 50 public types.