Is it better to use a class of another C# project by its class name. Like this
Buss_Logic.Class1 myClass1 = new Buss_Logic.Class1();
Buss_Logic.Class2 myClass2 = new Buss_Logic.Class2();
OR by using keyword on top of the file
using Buss_Logic;
As long as there is no namespace collision, it makes for more compact / easier to read code to include namespaces with the using keyword.
If there is ever any doubt as to where the class is defined, hover the mouse over the class name. The tool tip will show the fully qualified class name.
Use explicit namespaces if there is a namespace conflict (e.g. two classes called File in two different namespaces, where both classes are needed in the current source document).
Use a using at the top of the file as long as there are no conflicts in the names.
Given that the class themselves are clear enough, it makes the code easier to read.
Related
I have a question about the using statement for multiple files at once.
I have created an overload for a class that I want to use in my program.
To do so in one of my files I have added the following using statement.
using ClassName = CustomClassName;
This works, but only for that particular file.
Is there a way to get this to work for my entire project?
No.
using directives are per file.
You can always create a template that includes it.
No; C# does not have any such feature.
This is called type aliasing, re-utilizing the using keyword may be confusing, but it is not an import.
The purpose of this statement is to make a certain class accessible via a different name. This is useful in cases when you have different assemblies linked to your project which accidentally have classes with the same name.
If you for instance have A.dll that defines class Foo under the A namespace, and a B.dll assembly that also defines a Foo class under the B namespace, you can use:
using FooA = A.Foo;
using FooB = B.Foo;
to make distinctions between both.
The scope of this is usually the current file, although, if you happen to define multiple namespaces in the same file, you can scope that to the namespace within the file:
using FooA = A.Foo;
namespace N1
{
// knows about FooA;
using FooB = B.Foo;
}
namespace N2
{
// knows about FooA
// does not know about FooB
}
Practically you can make this aliasing more defined but no broader than the file's scope.
A simple solution for this is to create a template and use it into you project or class. this will give you a way to use the desire usings and directive as you wish.
here is a good sample to create a template .
http://www.rhyous.com/2010/02/17/how-to-modify-the-default-new-class-template-in-visual-studio-2008/
http://visualstudiomagazine.com/articles/2008/09/01/define-your-own-item-templates.aspx
I am creating a little Math library for myself contained within a single project and am running into some issues with namespaces. I have the project MyMathLib and the top level namespace:
namespace MyMathLib
{ ... }
and in a separate file...
namespace MyMathLib.Addition
{ ... }
and...
namespace MyMathLib.Subtraction
{ ... }
In the MyMathLib.Subtraction namespace I have a method that needs to use a static method SomeClass.Work() defined in MyMathLib.Addition so I included using MyMathLib.Addition at the beginning of the Subtraction file. But when I try to use the method it would like me to first qualify it with Addition.SomeClass.Work() and I want to be able to just type SomeClass.Work(). What am I doing wrong?
Thanks!
EDIT
Thanks for the suggestions! In each file, I actually named the class after the namespace (i.e. in the namespace MyMathLib.Addition is a static class Addition and in MyMathLib.Subtraction there is a static class Subtraction). Apparently this is what caused the issue (looking back, I should have stated this instead of using SomeClass). If I change the namespace to MyMathLib.MyAddition while keeping the static class as Addition, the using MyMathLib.MyAddition works as I want; that is, I can now just type Addition.Work() in my static Subtraction class. I've seen classes named the same as it's containing namespace before, could someone maybe explain why this is causing an issue? Shouldn't the compiler be able to determine whether I want to use the namespace or the class from the context of the code?
I'm guessing that you either have two classes called SomeClass that are both in namespaces you reference, or you have a variable or property named SomeClass. Either of these situations would make it impossible for the compiler to know that you're trying to call the static MyMathLib.Addition.SomeClass.Work() method, but the specific solution the compiler is suggesting makes it seem more likely to be the former.
Update
Seeing your edit, that makes sense. If you were using these in a namespace outside of MyMathLib, then you would still be able to avoid this namespace conflict. However, because you are inside the MyMathLib.Subtraction namespace, the compiler will implicitly consider any portion of the namespace "above" you to take precedence over class names. In this case, when you say "Addition", the compiler will look for the following items to resolve the name:
A class explicitly identified by a using ... = ... directive.
MyMathLib.Subtraction.Addition namespace.
MyMathLib.Addition namespace.
Addition namespace.
Any classes in the namespaces identified by using statements.
In this case, you're hitting #3 before #4, so you should be able to work around it either by renaming the class or namespace, or by using Yahia's suggestion (#1):
using Addition = MyMathLib.Addition.Addition;
Update 2
After looking at the article you linked to, it sounds like the explicit using statement still won't work. I guess item #1 actually gets evaluated down around item #4 instead. Bummer. You can use an alias to give the class a different name locally:
using Add = MyMathLib.Addition.Addition;
...
var add = new Add();
But the best solution is still probably just to avoid the namespace collision entirely by changing your namespace or class name.
try putting additionally the floowing line into your substraction source
using SomeClass = Addition.SomeClass;
http://msdn.microsoft.com/en-us/library/dfb3cx8s.aspx
http://www.blackwasp.co.uk/NamespaceAliasQualifier.aspx
Sounds like you're in the Subtraction namespace...add this to the top, inside the namespace declaration:
using Addition;
That should do the trick.
I have a webservice project with a class (let's refer to it as webservice.classA).
I have another class project producing a dll which references that class in its own namespace and instantiates an instance of it (lets call the dlls namespace dllnamespace).
In another project I want to access the member in the dll
e.g.
using webservice;
namespace other_project
{
class B
{
classA copy = null;
//....
dllnamespace.dostuff(); // amongst other things instantiates a classA object
//....
copy = dllnamespace.getclassA(); // method to return classA member
The compiler error I get is cannot convert type from dllnamespace.webservice.classA to other_project.webservice.classA
I guess I have a fundamental design flaw but I figure there must be (?) a way to declare/use "webservice.classA" in more than one namespace.
You have a name clash. The supported way of avoiding this (short of not naming your classes the same), is to define a using alias for one of the classes:
using webservice.classA = myWebserviceClassA;
You are right...the design flaw does exist in terms of naming.
Let us assume:
you have a class named
MyClass
the class exists both in namespace- abc.xyz.qwe.tyu.MyClass
and in namespace - sed.qwe.dfg.ert.MyClass
The workaround is -
using NS1 = abc.xyz.qwe.tyu.MyClass;
using NS2 = sed.qwe.dfg.ert.MyClass;
This way you avoid the clash.
Also, helpful to use if you have very long namespaces.
FURTHER REFERENCE : (From MSDN article on using Directive )
The scope of a using directive is
limited to the file in which it
appears.
Create a using alias to make it easier to qualify an identifier to a
namespace or type.
Create a using directive to use the types in a namespace without having to specify the namespace. A using directive does not give you access to any namespaces that are nested in the namespace you specify.
Change the copy definition line to:
dllnamespace.webservice.classA copy = null;
That's just the problem - you cannot have a class in more than one namespace. This is what namespaces were designed for - to prevent classes with the same name written by different people from aliasing. You'll need to decide for one of your namespaces to own that class and in the other one to import it. Alternatively if the dll and the web service are part of the same distributed app then they should use the same namespace.
I'm trying to design a class library for a particular engineering application and I'm trying to ensure that my class & namespace naming conventions make sense.
I have the following situation:
namespace Vehicle{
class Wheel{...} //base class for Wheel objects
class Engine{...} //base class for Engine objects
...
namespace Truck{
class Wheel: Vehicle.Wheel{...} //Truck specific Wheel object
class Engine: Vehicle.Engine{...} //Truck specific Engine object
...
}
namespace Car{
class Wheel: Vehicle.Wheel{...} //Car specific Wheel object
class Engine: Vehicle.Engine{...} //Car specific Engine object
...
}
...
}
The code gets used in ways that all of these classes will need to be referenced from within the same scope. The following situation would be likely:
...
Vehicle.Wheel.DoSomething();
Vehicle.Truck.Wheel.DoSomething();
Vehicle.Car.Wheel.DoSomething();
...
Under these circumstances, am I better off giving the classes more specific names
namespace Car{
class CarWheel: Vehicle.Wheel{...} //Car specific Wheel object
...
}
or leave the naming as shown in the first example and rely on the information that is encoded in the namespace for clarity? Under the latter approach, I assume I would want to utilize alaising for clarity in the code that makes use of this library, corret?
It seems redundent to have:
Vehicle.Car.CarWheel
or
Vehicle.Truck.TruckEngine
but I also want to have very descriptive and specific class names.
Philosophically, what I'm asking is whether or not to include the namespace as a part of the class name when considering if a class name is descriptive enough.
Typically namespaces are pluralized, so as not to collide with class names (e.g. it is likely you would want classes named Vehicle and Car) so I'd be inclined to use namespaces as follows:
namespace Vehicles;
namespace Vehicles.Cars;
namespace Vehicles.Trucks;
As for the names of classes, it would be typical to prefix the class name with the specialization, especially if they are likely to be used together, so you'd end up with something like:
class CarWheel : Wheel
class TruckWheel : Wheel
You can see this type of 'redundancy' everywhere in the .NET Framework, for example in the System.Xml namespace virtually all classes are prefixed with Xml, or in the System.Data.SqlClient namespace most classes are prefixed with Sql. It means that you can import namespaces with the using directive and then not have to fully-qualify class names throughout your code, e.g. which of the following is more readable?
Vehicles.Cars.Wheel wheel = new Vehicles.Cars.Wheel();
or
CarWheel wheel = new CarWheel();
It's obvious what both are doing, but the second is considerably shorter.
Note that if you do include the specialization in the name, then you may find that you don't need all the nested namespaces (.Cars, .Trucks, etc.) which can become painful if they are usually used together, and so every file using them would have to import all the namespaces, e.g.
using Vehicles;
using Vehicles.Cars;
using Vehicles.Trucks;
using Vehicles.SomethingElse;
using Vehicles.YetAnotherThing;
If you find this same stack of using directives is at the top of each file, then collapse the classes down into a single namespace. You typically include all related functionality that is expected to be used together in a single namespace, and only use nested ones for functionality that extends the base namespace but is less frequently used.
I would try to avoid reusing names across different namespaces, particularly if a client may want to use both in the same program.
Do you really need a namespace for Car, Truck etc? All these namespaces sound more like they ought to be classes than namespacese. Perhaps in your real situation it makes more sense though...
Can I expose a class from another .net namespace as a class in my namespace? I use a class - antlr.collections.AST - as the return type for a function belonging to a class in my namespace; as a result, the user has to have
using antlr.collections;
using myNamespace;
at the top of their files in order to use my function. Can I make myNamespace.AST an alias for antlr.collections.AST, such that the user only has to have
using myNamespace;
at the top of their files?
Bear in mind that the consumers of your code won't actually need to have using statements. Those are there to make their lives easier, so they don't have to type antlr.collections.Foo and antlr.collections.Bar all over their source.
The bigger "impact" (if indeed there really is a severe one) is that the consumer of your code will need a hard reference to the assembly where antlr.collections is defined.
However, if that's documented up front, I honestly don't see it being that big of a problem. It's no different than the consumer of a SubSonic-generated DAL needing references both to the generated DAL assembly and the original SubSonic assembly. (And, quite possibly, using statements as well.)
Dependencies are what they are. There's a reason classes are broken into namespaces -- primarily for organization and to reduce naming conflicts. Not knowing what classes are in the namespace you mention, I don't know how likely such a conflict actually is in your scenario ... But attempting to move the class from one namespace to another, or to hide the fact that such is needed by deriving a blank class from it, is probably not the best idea. It won't kill the consumers of your class to have another reference and using statement.
How about deriving a class using the same name in the new namespace? I meant:
namespace MyForms {
class Class1 : Some.Other.Namespace.Class1 {
// ...
}
}
create a new class that inherits the class in your new namespace. It's not ideal, but it's useful for unit testing and the like.
You should think about why you are doing this though, classes are broken up into namespaces for a reason.
No, you can't.
The full path to and name of a class is part of its identity.
If you derive from the class and return your derived class, you'll make yourself responsible for providing all of the documentation for the return type.
I think you'll be doing the developers who use your library a disservice because they won't necessarily know that what they're really working with is a type from antir.collections (not that I even know what that is, but that's not the point). If the developer comes to StackOverflow.com searching for information on that return type, are they more likely to find information if the type is from a "common" library, or from yours?
The only solution is to hide the whole dependency to the type antlr.collections.AST.
You can use an Adapter fot that purpose.