current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite
1

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?

share|improve this question
add comment

closed as primarily opinion-based by MichaelT, Dan Pichelman, Kilian Foth, gnat, Bart van Ingen Schenau Sep 15 '13 at 15:07

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

up vote 2 down vote

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?

share|improve this answer
    
very good advices (: ~ maybe i should name DBConnection then? Or is the full name better? DatabaseConnection...I guess I shouldn't be afraid of long names right? :p –  hugo_leonardo Jan 31 '13 at 11:04
    
DbConnection is used in System.Data.Common. If someone is using your library alongside other databases, DbConnection will be ambiguous. They will have to fully qualify System.Data.Common.DbConnection and MyFramework.Database.DbConnection. It's for you to decide whether this will be an issue. Don't be afraid of long names. MyFrameworkConnection makes it perfectly clear what the class does. –  Hand-E-Food Jan 31 '13 at 22:36
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.