mono tutorial; namespaces

Code junkies hangout here

Moderators: ChrisThornett, LXF moderators

mono tutorial; namespaces

Postby lis » Thu Nov 30, 2006 2:21 pm

Hi,

I'm joining the Mono Tutorial from the magazine, using SuSE with kde for it.
In the codeExample from the first project, helloWorld ( ;-) ), the namespace is missing.

My question is:
Does a library have to exsist before you can give it a name in the code ?
Or can I just enter the missing line "namespace HelloWorld" without knowing if this library does exist ?

Thanx in advance.

Lis
User avatar
lis
 
Posts: 57
Joined: Thu Nov 30, 2006 1:50 pm
Location: Noord Holland, the Netherlands

RE: mono tutorial; namespaces

Postby dfuller » Sun Dec 10, 2006 9:33 am

Hi Lis,

You don't necessarily have to specify a namespace although it is good practice to do so.

In answer to your question a namespace is just a way of organsing your code and avoiding duplicate names in code, in the HelloWorld example there wasn't alot happening so it wasn't absolutely necessary to add a namespace. By adding the "Namespace HelloWorld" part we are effectively creating a new namespace (or adding to one if it already exists).

Imagine though if you were creating an application based on a car, we want to create a method which opens a car door and another which opens the boot. Without namespaces we would have to create two methods, one called OpenCarDoor() and another called OpenCarBoot(). This would work but it would suck because we know that the door and boot are seperate objects, using namespaces we could create everything for the door in a Door namespace and everything for the boot in a Boot namespace and have a method in each called Open(). So in our code we could then just say Door.Open() and Boot.Open() which looks alot nicer, it also means we could use other method names in both such as Lock() and UnLock() without having to worry if we are using the same name somewhere else.

Hope that helps.

Daz
dfuller
 
Posts: 33
Joined: Sat Jul 02, 2005 10:46 am
Location: Derbyshire

Postby lis » Mon Dec 11, 2006 6:35 pm

Hi Daz,

Thanx 4 your reply.
So a namespace is just a way to order things.
Thanx for clearing that up for me.

Would you maybe have a link for me to get on with Mono ?
Thanx in advance.
Lis
User avatar
lis
 
Posts: 57
Joined: Thu Nov 30, 2006 1:50 pm
Location: Noord Holland, the Netherlands

Postby lis » Tue Dec 12, 2006 7:48 am

Found one.
http://www.gotmono.com/docs/

(Weird that I did not see that earlier.)
Hurray 4 eee PC :)
User avatar
lis
 
Posts: 57
Joined: Thu Nov 30, 2006 1:50 pm
Location: Noord Holland, the Netherlands

Postby dfuller » Wed Dec 13, 2006 11:12 am

Hey Lis,

Only just read your message, nice one on the link, I'm in the process of trying to apply what I now with the MS implementation to Mono so that should come in useful.
dfuller
 
Posts: 33
Joined: Sat Jul 02, 2005 10:46 am
Location: Derbyshire

namespace vs class

Postby SIGSEGV » Sat Dec 23, 2006 7:40 pm

Nice explanation dfuller, but im wondering when to use a namespace and when to use a class for something..

I don't know a lot about mono yet, but i'm guessing that it still supports classes like c++ does. However, this is also something i've been wondering about with c++...

In stead of a namespace called 'Door', we could also use a class called 'Door' and create several objects of that class for the normal doors and the boot. I guess it would be better to use a class for a door-like object, as one could derive from a class and not from a namespace. For instance, you might want to derive the boot class from the door class because a boot normally doesn't have a window that can open and a normal door can and also the window in the boot may have a screen wiper, which i've never seen on a normal cardoor. But maybee this is a bad example to clarify this.
I guess it would be bad to derive a boot from a door, just because they share some properties.. It is kind of like deriving an apple from an orange because they are both fruit, imho.. I would prefer creating a class cFruit and deriving cApple and cCitrusFruit from it and then deriving cOrange, cGrapefruit and cLemon from cCitrusFruit and then several different kinds of apples from cApple.

So far i've used namespaces for things that one would never derive from and classes for things that one might derive from. For instance, in my c++ gameserver, i have a namespace called network which contains classes like cPacket, cSocket, cClientSocket, cMasterSocket, cSocketSet and cSocketServicer. But i also have a namespace called thread which contains classes like cThread, cSafeThread, cMutex and cThreadManager.

Am i using classes and namespaces in the right way? How is this in mono/.net?
0x2b | ~0x2b ?
0xff !
User avatar
SIGSEGV
 
Posts: 41
Joined: Sat Apr 29, 2006 4:20 pm
Location: Almere, Netherlands

RE: namespace vs class

Postby TonyLB » Fri Dec 29, 2006 12:28 pm

Having just started with mono and c# it seems to me that the namespace has a lot in common with the java package approach. Packages are used to collect together a bunch of classes which either share some common link or make up the custom part of an application (I have a package called utilities, first type, and one called j3dbuilder, second type).

A class on the other hand is-a something, which is a much tighter linkage. A vehicle is-a thing. When developing some transportation application I might have a package transportApp with a class vehicle and subclasses car, bike etc.

This is pretty much the OO approach. You might like to look at some of the stuff about UML which goes into the design of OO systems and which covers these ideas much better.

Tony
In the beginning was nothing, which exploded! (Lords and Ladies, Terry Pratchett)
TonyLB
LXF regular
 
Posts: 112
Joined: Tue Apr 12, 2005 7:08 pm
Location: Wirral, UK

RE: namespace vs class

Postby dfuller » Wed Jan 03, 2007 1:23 pm

Hey guys, sorry it's taken a while for a reply.

I suppose the Door example was a little restricted in it's approach as you are right in that it could be handled better using classes and inheritance/polymorphism. A better idea might be to think of namespaces as ways of grouping together classes, static methods and other functionality.

A really good example of this is in the .NET framework itself where common item are located in the System namespace, file access is found in the System.IO namespace and Arrays and Hashtables are found in the Sysem.Collections namespace. This of course only looks at two levels but they can go much further than that.

One of the things I do a lot of at the moment is writing class libraries at work, these compile into DLL's which others can then include in their libraries or front ends which all combine to create a larger application. So for instance we might be working on an application called MyApp, in here we know we are going to need some business objects (we'll say Employees and Divisions), it's going to need some basic validation code for things like phone numbers and emails, it's also going to need a front end.

I might go and make a start on the business objects in a namespace called MyApp.BusinessObjects, now I've figured (rightly or wrongly) that all my employees are going to have certain features which are common accross all types, so programmers, janitors, managers are all going to get paid, they will all have a home address and they all have core hours (I know this makes it all to easy but I like that). So I decide to create an IEmployee interface (or template depending on your background) and all my employee classes will implement it. So I manage all of these classes under a new namespace called MyApp.BusinessObjects.Employees, I then do something similair with the divisions called MyApp.BusinessObjects.Divisions

So now if the person writing the front end wants to do something with employees they will first need to include the DLL I provide them into their application and then reference the objects, they can do this either directly in their code

MyApp.BusinessObjects.Employees.Manager myManager = new MyApp.BusinessObjects.Employees.Manager())

or they could put a using statement at the top of their code file as follows:
Code: Select all
using MyApp.BusinessObjects.Employees;

public class MyClass
{
    public void MyMethod()
    {
        Manager myManager = new Manager();
    }
}


or

Code: Select all
using MyApp.BusinessObjects;

public class MyClass
{
    public void MyMethod()
    {
        Employees.Manager myManager = new Employees.Manager()
    }
}


Doing things this way keeps the code cleaner and more manageable. I covered quite a few things there some which haven't been mentioned yet in the tutorials but I hope it makes sense. If not let me know and I'll try to explain things better.
dfuller
 
Posts: 33
Joined: Sat Jul 02, 2005 10:46 am
Location: Derbyshire


Return to Programming

Who is online

Users browsing this forum: No registered users and 1 guest