class or object..??

Hey, i want to create a create an object or class (not really sure which one) that can keep track of player data. Like the following:

class player
{
playerid;
playername;
playerposition;
playerlevel;
etc...
etc...
}

But i'm not really sure how to do this. I was thinking of creating a class for this.

So suppose im in my "sockRecieve" class. In that class, a player (player 1) connects and i need to create an object/class for this player. So i can keep track of who he is and what position he has.

So if the player connects i want to be able to fill the variables like so:

player.playerid = 1;
player.playername = "blaat";
etc..
etc..

But i don't want to keep track of one player, i need to keep track of multiple players. So how can i effectivly store data of more than one player? Should i use an object for this or a class??

And more importntly, how do i do that??

I think it's possible with a class. I'm trying some stuff but it isn't working yet.
This is what i have so far:

This is my new class

Code:

---

namespace server
{
    class player
    {
        int        m_iAmountOfPlayers;
        string      m_szName;
        int        m_iXYZPos;

        public player()
        {
            m_iAmountOfPlayers++;
        }

        public void setPlayerName ( string szName )
        {
            m_szName = szName;
        }

        public int getAmountOfPlayers ( )
        {
            return m_iAmountOfPlayers;
        }
    }
}

---

Then in my main class i do the following to create an instance (array) of that class and access the members:

Code:

---

        public Form1()
        {
            InitializeComponent();
            player[] cPlayer = new player[10];

        }

---

Code:

---


                cPlayer[0] = new player();
                cPlayer. //No access to the functions in the player class...

---

But for some reason this isn't working. I can't call the functions that are inside the player class. Both classes are in the same namespace.

Hi

I believe it should be:

Code:

---


cPlayer[0].SomeMethod();

---

K Nemelka

Quote:

---

Originally Posted by Trainwreck

I think it's possible with a class. I'm trying some stuff but it isn't working yet.

---

As I have read in your first post you are unsure about what a class really is because each class is an object. So I would really suggest you to read a good starterbook for C# and additional one about Object orientated programming, as you seem to have lots of misunderstoods here.
To answer your request. The whole code is ... lets say :rolleyes:
To show you the obviousest errors. Your code:

Code:

---

namespace server
{
    class player
    {
        int        m_iAmountOfPlayers;
        string      m_szName;
        int        m_iXYZPos;
 
        public player()
        {
            m_iAmountOfPlayers++;
        }

---

What are you trying to accomplish here
if you want to set iAmountOfPlayers to one why nor simple initialise it in the defienition like

Code:

---

private  int    m_iAmountOfPlayers = 1;

---

You didn't expect that. But creating one instance of your player class always would end up that this vaue is simple set to '1'
In every instance of this class.

Code:

---

        public Form1()
        {
            InitializeComponent();
            player[] cPlayer = new player[10];
 
        }

---

This is basically ok and you will get an array of 10 players

Code:

---


                cPlayer[0] = new player();
                cPlayer. //No access to the functions in the player class...

---

if you want to access one specific player you need to do

Code:

---

cPlayer[0].setPlayerName("Jonny")

---

Your method

Code:

---

      public int getAmountOfPlayers ( )
        {
            return m_iAmountOfPlayers;
        }

---

Always will show '1' as a result, because this class is the class player and not players.
If you want to have a class of players then you need to create one. Maybe use a list therein like

Code:

---

List<player> _allplayers = new List<player>

---

Just a note to your naming conventions. Look at MS about Pascal and camel Notation and when you should use a big Letter in the beginning and when you are using small letters in the beginning.
For example look here
http://msdn.microsoft.com/en-us/libr...72(VS.71).aspx
or also here
http://www.irritatedvowel.com/Progra...Standards.aspx

Thanks alot for explaining that, everything seems to be alot more understandable now :)

Look up the term "primitive obsession" - learn from it and avoid using primitives as parameters, it really comes up to bite your rear later on in software projects. Here's a suggestion for your code:

Code:

---

public class PersonName
{
        public string Name{ get; set; }
}


public class Position
{
        public int X{ get; set; }
        public int Y{ get; set; }
        public int Z{ get; set; }
}

public class Player
{
        private static int        _totalPlayers;
        public  PersonName  PlayerName;
        public        Position        XYZPosition;


        public static int TotalPlayers
        {
                get
                {
                        return _totalPlayers;
                }
        }

        public Player( )
        {
                // increase the total amount of players
                _totalPlayers++;
        }

        ~Player( )
        {
                _totalPlayers--;
        }
}

---

The point I would like to add here is that you can have the PersonName and Position Objects evaluate themselves, thus avoiding a bunch of code that becomes hard to test.

Additionally, you can later extend both of these value objects (PersonName and XYZPosition) without breaking existing code. If, for example, you later decide to create a class EscapationPosition that also contains a time factor, it will still be valid to use in all the functions where you require an X, Y and Z.

Let primitive data types exist only to declare internal class members, never use them as parameters ;)

Quote:

---

Originally Posted by Efitap

Look up the term "primitive obsession" - learn from it and avoid using primitives as parameters, it really comes up to bite your rear later on in software projects.

---

Yea this is basically right but maybe a bit toooo advanced to be understood by a beginner. :D

For a short explanation. All the checking of dataformats and validating data can be done into a small class for each primitive typ used as a property and instead of having a property which contains the string as a phone number you maybe want to have a class there which checks if the input really seems to be a phone number and sucht things more. ( Which normally is done by the use of Regex matching ) Or in the example of three dimensions for example there may be lmits for each of those values and they could be implemented to the class by its Constructor. This way the dimension class would be able to check if the size of one of the params exceeds its borders and may react in a defined way like throwing an exception. But this may depend on what is needed and wanted.

The learning concept is:
a) Get all the basics in, so you understand what you are doing
For getting this done do lots of selfwritten examples ( never copy them from a book, always type yourself ) and do an enourmous amount of debugging the code

b) After you are totally sure about a) read some more advanced books about C# design patterns do the examples there and look what will change in your understanding

c) During being on Point b) you normally will find things like "primitive obsession" or "Bad Smells" and this will bring you on the route to be an excellent programmer.

Warning: Failure to keep in this order may result in feeling like a fool or 'giving up' all that complicated stuff.

So have fun and always feel free to ask. :D

Quote:

---

Originally Posted by Efitap

Let primitive data types exist only to declare internal class members, never use them as parameters ;)

---

Never? Seems a bit overboard to me. I don't think that I will be creating a wrapper class every time I need to pass in an int.

Quote:

---

Originally Posted by BigEd781

Never? Seems a bit overboard to me. I don't think that I will be creating a wrapper class every time I need to pass in an int.

---

I have also read this article, where it is explained what really was ment. Its a bit in another light then he mentioned it here. I have tried to explain a small bit of it.

Basically if you never would have a primitive type as an parameter this would end up in chaos because just that class, which will be used to replace the integer or the string in the end needs again in and out properties. So if you follow his 'never' then also this would be sunbstituted with again a wrapper .... He substituted the params X,Y, Z together in a new class OK.

Code:

---

public class Position
{
        public int X{ get; set; }
        public int Y{ get; set; }
        public int Z{ get; set; }
}

---

But now we still have three Properties which would need to be wrapped:lol: The problem would have been only switched from one class to the next The new class would need to write implicit and explicit castings and... then we could wrapp every single value again, because here we still have primitives as params. :lol:
In the end we would awake with wrapper holds wrapper holds wrapper ...Noooo.
BTW The example doesn't show why this should be done, because having VS 20008's 'automatic' properties like the example showed is useless at all.

In all this techniques you need to let the church in the village as we say in Austria. This means you really need to know what your class does and if you want some typechecking if it simple could be done in the already existing class just in the property itself or if it is better to have this small classes. So say 'never use them as parameters is really a lot of overdone. :D

Sure if I have a really big class that itself gets to be a horrible mess because you have fifty primitives as params and all of them needs some sort of validation, notifiction messages for their changes and such stuff, then it could help to clean up this class to change from primitives to small wrapper classes which do this work and getting your big class in an easier readable much smaller and securer, one.

In my view also testing is much easier when you have small classes then a huge one.

But all together its not just the best idea to explain this to a new person who obviously has difficulties in his first steps to create a class. It maybe confuses more then it helps

Quote:

---

Originally Posted by JonnyPoet

Basically if you never would have a primitive type as an parameter this would end up in chaos because just that class, which will be used to replace the integer or the string in the end needs again in and out properties. So if you follow his 'never' then also this would be sunbstituted with again a wrapper ....

---

I follow your thought, but it is not right. Value objects are just that to begin with, they are meant to be placeholders for a primitive data type, possibly also self-checking, but because they are value objects, they must be allowed to have primitive types.

I believe you were confusing value objects with domain objects, which are two separate entities.

Quote:

---

Sure if I have a really big class that itself gets to be a horrible mess because you have fifty primitives as params and all of them needs some sort of validation, notifiction messages for their changes and such stuff, then it could help to clean up this class to change from primitives to small wrapper classes which do this work and getting your big class in an easier readable much smaller and securer, one.

---

What you are describing here is domain objects :)

Quote:

---

In my view also testing is much easier when you have small classes then a huge one.

But all together its not just the best idea to explain this to a new person who obviously has difficulties in his first steps to create a class. It maybe confuses more then it helps

---

I believe that the sooner you get rid of the bad habits given by teachers with little/no real world programming experience, the more value you add to the developer to be.

Primitive Obsession is a term that is so easy to understand, and it has a huge impact out in the real world. Your new employer will love you to death for knowing and avoiding this. 3 Functions in a program that accept integer values can be called by the wrong functions, because the developer did not know their meaning (ever seen that one happen?). With object parameters instead of primitives, you cannot make a mistake, the compiler won¨t let you insert a PersonId instead of that OrderId because they are not the same type. Using ints, they would be, and you would have a hard-to-catch bug that is hard to spot and easy to miss.

It also follows good object oriented practice to use objects instead of primitives. If a function is expected to look up a person by it's PersonId, ,then a PersonId object is what the function accepts, and not the integer, wouldn't you agree? It is semantically more correct.

These are just tips for becoming a beter developer tho, and the consept of primitive obsession is easy enough to understand. If this forum is not for giving advice, but only solve school assignments, then I apologize :)

A quick thing that I forgot to mention (that came to me whilst replying to another post):

Wrapping your parameters into value objects turns them into reference types. So if you have in your program 10 000 person objects, and you need to set their default shoenumbers, calling

Code:

---

int newNumber = 42;

foreach( Person person in Persons )
{
  // Passing the integer creates a copy of it
  person.SetShoeNumber( newNumber );
}

---

Will cost you 10 000 extra copies of newNumber while this:

Code:

---

ShoeNumber newNumber = new ShoeNumber( 42 );

foreach( Person person in Persons )
{
  // Passing the object creates a reference
  person.SetShoeNumber( newNumber );
}

---

For the sharp ones, you can see no improvement here as a reference is the size of an int anyways, but still, it is better programming, cleaner code, and if I ever need to change the meaning of shoenumber, or add behaviour to it, I will not have to modify any of my existing code to do so.

Quote:

---

Originally Posted by Efitap

...
If this forum is not for giving advice, but only solve school assignments, then I apologize :)

---

I have got most of your points before I typed my :D post but as you had written 'never' - you didn't explain at this time that there is a difference between domain classes and Value objects :D I felt a need to be a bit provocatve.

The main point in my post is still learning gradient and overwhelming students. by simple giving tooo much information to people with obviously no experience. I also wouldn't talk to a young apprentiece who wants to learn repairing a TV about complicated techniques in this electronics like PAL recognition or Quad modulation in his first days. The student may take his hat and run away. Believe me - even good information can be really too much. An example:
My son studies IT and I once asked him about a database problem. He knows my level of experience and by that he thought he could talk to me like he would talk with fellow students forgetting I have a practical but no mathematical theorethical background in this. In the late 60th when I ended school there was no such thing like datase theorie at technical school. After half an hour of information I was totally confused and had given up. All information was per sure correct good info, but it was simple too much.

So I'm always looking to the knowingness level of a person when answering a post and trying to give just the needed information.

What should a youngster who just has learned about classes and done some simple examples in school (where normally only primitives are used as properties ) think when just another one comes and tells him: 'Never use primitives as properties ! :eek:'

I personally would have been confused in that position.

Another point is that the name of this is 'primitive obsession' and an obsession would it be if a person feels the urgent need to do something.

Sorry IMHO always person can go the other way and becoming to get 'Objects Obession' :D programmers. Believe me in about 30 years of programming I have seen so much ideas about how a good program should be done and they have been coming and going, this is a field of permanent changes and we all always have to learn this one and to forget that one ( which maybe was a good practice for years ), so in my opinion this is unfortunatly also acommercial aspect of programming costs, so we all permanent have to decide which 'best practices' to use and which are to overdone for a project.
I have done programs that have 100.000 and more lines and never had a problem that an supplierId was used instead of a productID only because both are int32 values. To differ here we simple have the system of talking names, so this is not a cogent example that really shows me the needs of 'never' using an primitive.
More security because the compiler will show you an error. ?
Have you ever had an error because an object was forgot to initialize ? You may get secure so you cannot use the wrong ID in your example, but whats if you simple forget to initialize your value ? In my world you simple can overdo everything and sorry some things are going into that direction sometimes.
Refraction of code and reuseability was always a theme as long as we are doing programming. A balanced use of such things like wrapping a primitive, especially when there is an additional benefit like validation tests and all that is a very good technique, no daubt, but only and ever - IMHO No. All in live what is going to excessive and exclusive at least will not be survival. there is nothing which is
'Only , 'Exclusive' or 'Always' and 'Ever' in this world. Exceptions are the salt in the soup in this world :D

Quote:

---

Originally Posted by Efitap

A quick thing that I forgot to mention (that came to me whilst replying to another post):

Wrapping your parameters into value objects turns them into reference types. .

---

Yes sure and reference types have advantages and disadvantages.
The disadvantage comes up if you simple need a copy of a value and you dont want to change the original one, you need to take care to that fact so inside your domain class you cannot use that object because changing the value inside the wrapper in domain class A would also change the value in the same wrapper object which comes from domain class B. So you need to unwrap the value inside your domain class get properties, and to wrap it in the set property, isn't it ? As also mentioned before, things like implicit and explicit casting maybe needs to be added to this wrapper class.
Hmm. not such an easy stuff for a new programmer, isn't it.
After a short a youngster will come and tell you I have done as I have heard and not used primitives but I have run into the following troubles.... Again, nothing against this approach, the future wll show if this proves, but for beginners :eek:, IMHO sorry no.

Quote:

---

Originally Posted by JonnyPoet

by simple giving tooo much information to people with obviously no experience.

---

If a student is too stupid to understand the concept, he should quit immediately. This is not rocket science, it's a fundament of OOP that is simple to understand, and touches the very base of the entire concept.

Quote:

---

So I'm always looking to the knowingness level of a person when answering a post and trying to give just the needed information.

---

"Give a man a fish, and you've fed him for a day. Teach a man to fish, and you have fed him for a lifetime". If you only reply to their school assignments, you do nothing but make them dumber.

Quote:

---

Another point is that the name of this is 'primitive obsession' and an obsession would it be if a person feels the urgent need to do something.

---

It is a commonly known term in OOP. I'm surprised that you do not know about it with your 30 odd years of development? I've known about it for at least 10 years now..? Maybe you are becoming outdated?

Quote:

---

Sorry IMHO always person can go the other way and becoming to get 'Objects Obession' :D programmers.

---

Possibly, but without it, you can't really call yourself an object oriented developer, if you do not understand OOP, can you?

Quote:

---

I have done programs that have 100.000 and more lines and never had a problem that an supplierId was used instead of a productID only because both are int32 values. To differ here we simple have the system of talking names, so this is not a cogent example that really shows me the needs of 'never' using an primitive.

---

I've seen plenty of miserable code with more lines than that. What is your point here?

Quote:

---

A balanced use of such things like wrapping a primitive, especially when there is an additional benefit like validation tests and all that is a very good technique, no daubt, but only and ever - IMHO No. All in live what is going to excessive and exclusive at least will not be survival. there is nothing which is
'Only , 'Exclusive' or 'Always' and 'Ever' in this world. Exceptions are the salt in the soup in this world :D

---

I agree, I often abuse the words "never", "always" etc to drive a point through and to spark a reaction. I can tell from your wish for balanced use of wrapping primitives that you have misunderstood the point. Think of it as blinking the lights of your car when you are driving. It is a good habit to do so, even when there is nobody around, because then it becomes an instinctive reaction that you do without thinking about it - and it is a good practice because you become a better driver as a result of it.

The same is true for good habits in programming. There are various things one can do to improve the quality of code. Enhance readability, work in a continuous integration environment, following one or more of the Agile methods, and, as one of the simplest concepts, you can avoid passing primitive datatypes as parameters to functions - this is considered a bad practice for oop.

Quote:

---

Originally Posted by Efitap

If a student is too stupid to understand the concept, he should quit immediately. This is not rocket science, it's a fundament of OOP that is simple to understand, and touches the very base of the entire concept.

---

This is not the way to teach. Maybe its in modern times - the result- disaster - is seen all over the world and has begun with a method called 'look and say' method' German 'Ganzheitsmethode' which means you didn't learn the alphabet first and then the full word but instead just the other way round. And in simple mathematics 'theory of sets' was introduced into groundscool which in my schooltime was only learned at univerities ! This was the way down to gettin the school system ruined as we have it now about 40 years after this action was started in Europe by some psychs who infiltrated school system with thei brilliant ideas. Ok thats a bit of topic.

But generally you cannot switch off your mind. If you read somthing you cannot understand and is against anything just learned in school you only get confused, nothing else.

Quote:

---

Give a man a fish, and you've fed him for a day. Teach a man to fish, and you have fed him for a lifetime". If you only reply to their school assignments, you do nothing but make them dumber.

---

I'm totally with you in that point. School system makes people often dumber. But in the reason behind we are different.
It is totally Ok that school systems at first are learning people to design a simple class, just as they will need for designing classes for substituting primitives. But what you are trying to teach a newcomer is materials which are part of lectures in IT Highschools about refractoring and modern softwaredesign. So believe me, I dont doubt your honest desire to help but always look for the gradient, to whom you are telling which technical details. I was in the field of instructing our trainees for more then 20 years and we got real great TV- technicians as a result, but I always looked at the point 'Feeding a person to much is unhealthy'

Quote:

---

I've seen plenty of miserable code with more lines than that

---

:rolleyes: Do I hear a bit of arrogance here ? The point was simple said again.: There was no need for NEVER using primitives. They had been used because it was cheaper then building up objects for each simple iD. And theory is a great thing especially IT professors knows a lot about theory. :D Practice always differs between theory and what is really needed and doable in a given time and cost frame.
Also there is a big difference if you are working for a big softwarefirm or if you do simple inhouse software.

Quote:

---

I've known about it for at least 10 years now..? Maybe you are becoming outdated?

---

I think Martin Frowler was one of the first where i read about it I have forgot if it was in the early or the late 90th, but it was in the time where I worked mostly with VB 6.0 and in this language it really was of no interest for me. It has coe to my eyes again in the last few years but I'm still as you see not totally convinced about the generallity which you are trying to explain. All whats done needs to be done with a viewpoint of usefulness and Necessity.

Readability of code is a good point in my eyes, as I myself hate big classes too - after a short, you cannot manage them
Security against errors as I pointed out is not the point I would agree to be a main breakpoint for using classes only.

So this are the points where I'm looking how to design. Is the class still readable. What will be the advantages of using a class instaed of a primitive in a given projects class. Is the class only a wrapper itself -- all that. So I'm very seldom in a way of 'never' and 'always' :wave:
But thats me and thats you and that's simple the difference.

---- edited ----
I only want to add one small point as this was funny for me.

Quote:

---

Think of it as blinking the lights of your car when you are driving. It is a good habit to do so, even when there is nobody around...

---

Yes maybe but I'm not a robot when driving. I'm just a thinking person and I must confess if there is a shield which says parking forbidden - but nobody is there - I'm looking around if there is really nobody to be seen and then I'm parking :D:D If I've luck then i dont need to drive around 5 minutes to find a space, in a bad case if I havn't seen the sometimes hiding cops waiting for a person like me to charge some extra 21 Euros for breaking the rules :lol:

And at last: Thx for the interesting and funny conversation