I’m resistant to calling the “main” class the same as the namespace, but I sometimes find myself needing it. Considering I’m using the Vendor.Namespace.[Subnamespace].Class formula, imagine this scenario:
[MyFramework]
[Database]
Database
Sql
Schema
DriverAbstract
DriverInterface
[Drivers]
Mysql
Postgresql
Sqlite
obs: [] are for namespaces, the others are classes.
Now, I could call the Database class Connection instead, but when I import the namespace MyFramework.Database I would only see Connection in the code (but connection to what?). Other solution would be calling it DatabaseConnection, but is that really necessary? I would like to hear your thoughts and ideas on that problem. Thank you (:
Sidequest: also, what are your thougths on DriverAbstract and DriverInterface? Should they fit better in the [Drivers] namespace? Should I call DriverAbstract just Driver?
While you haven’t specified a language, some of the tips provided for .Net laguages apply to all languages: Names of Namespaces.
Do not use the same name for a namespace and a type in that namespace. For example, do not use Debug for a namespace name and also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.
Do not introduce generic type names such as Element, Node, Log, and Message. There is a very high probability it would lead to type name conflicts in common scenarios. You should qualify the generic type names (FormElement, XmlNode EventLog, SoapMessage).
If the Database class is public, I’d think about naming it MyFrameworkConnection. At a minimum I would avoid naming it Database due to it conflicting with the namespace.
Consider this scenario.
namespace Database
{
public class Database
{
public static object Schema { get; private set; }
}
public class Schema {
...
}
}
What happens when you refer to:
Database.Schema
Does it return the value of Schema from the Database class, or does it return the Schema type from the Database namespace?
2