My thoughts on C#

[Luc Pattyn]

Hi, Classes get instantiated into objects; all the objects from a single class have the same behavior. Most often these objects are tangible, real-life objects. They have properties that describe them (Age, Color, Size, etc) and methods that operate on them. In an adventure game you would have one or more Adventurer, lots of Rooms, each Room could have Door objects and Window objects, each Adventurer would have an Inventory, an Inventory would hold InventoryItems which could be Keys and Slippers (deriving from InventoryItem), etc. None of these classes would be named after verbs, a get/drop class makes no sense whatsoever. A Get() or a Drop() method would make lots of sense on InventoryItems. If you want to learn object-oriented programming (OOP) then please study the matter by reading a book on the subject, before you start designing and coding. If you refuse to learn OOP properly then please don't touch any of the languages that are intended for OOP, such as Java or C#. FYI: C++ was launched trying to support OOP while maintaining compatibility with non-OOP practices (as in C). I have never been convinced C++ did the programming world a favor. However I am sure Java and C# do. Except maybe for the latest syntax-sugaring additions to those languages. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[realJSOP]

Brian_TheLion wrote:

it seems that you need to keep within certain rules to have the program compile.

Well, that's true of ANY language.

Brian_TheLion wrote:

Maybe some programs are better suited to C# than others.

That's not true at all.

Brian_TheLion wrote:

All programs seem to have a user interface as I've never come across a program that only runs under the DOS prompt.

Again, not true at all. Having a GUI is pretty much dependent on what/who the app is for. I've written several command line apps in the last four months for our DBAs to run from SQL Agents. These apps didn't need a ui.

Brian_TheLion wrote:

I'm being drawn towards C++ as it does allow global variables compared to C#.

If you want global vars, simply create a static Globals class and add the properties and methods you need in it. I do it all the time. In point of fact, EVERY app I write has a static Globals class for that very reason. FWIW, I transitioned from unmanaged C++ to C# back in 2007. It's really not that difficult to do.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[realJSOP]

Dave Kreskowiak wrote:

"Global variables", in my humble opinion, are a lazy and error prone way of moving data between objects.

But like in C++, you don't want to have to reallocate memory every time you need static data. "Global" (static) properties and methods are still a necessary and vital construct in C#. For instance, I have a static SessionVars object in my web apps that provide a foolproof (and type-safe) method for accessing session variables. It's "globally" accessible to the entire app (controllers, views, and other classes). I also have a static Globals class that provides properties (that don't belong in SessionVars) and methods for the entire app. Classifying all "global" objects as the crutch of the lazy programmer is pretty - well - globally wrong. Like any other construct, you have to use static classes apporpriately.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[realJSOP]

Richard MacCutchan wrote:

As others have mentioned, global variables tend to cause more problems than they solve; don't use them.

He can get his "global" accessibility by creating a static class. I don't understand (and have never seen) a global static class present problems.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[Dave Kreskowiak]

Brian_TheLion wrote:

You have an inventory class and a get/drop class

No you wouldn't. You would have an Inventory class with Add, Get, and Drop methods. A class is always a noun. The methods exposed by the class are always verbs that perform operations on that noun. Your Inventory class should never output messages to the console. UI operations have nothing to do with managing the data stored by the Inventory class. This is true for ANY OOP language, including C++ and Java.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

[Dave Kreskowiak]

Using variables themselves for passing data to everywhere, like in the old BASIC days, is lazy in an OOP environment. Doing so is an attempt to bypass OOP principles and avoid learning how to do it correctly. I never said there is never a need for globally accessible DATA. I'm saying using global VARIABLES (outside of a class, because the old non-OOP days is where this idea comes from) to hold that data is the wrong way to do it. It's not even possible to do that in C# anyway, where everything must be in a class somewhere. Static classes are a good thing where globally accessible data can be managed properly, but, as you said, must be done appropriately and for the correct reasons.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

[Dave Kreskowiak]

Brian_TheLion wrote:

The original code was written in the BASIC language back in the 1980's

There's the problem. You're trying to force the old, non-OPP code way of doing things into an OOP world where it just doesn't work. You cannot do a line-for-line conversion. You have to understand what the INTENT of the old code and rewrite using modern techniques. This is will result is radically different code because BASIC is NOT VB.NET, or C#, or Java, or C++. You know that your app needs an inventory. How that's implemented in the new version is going to be done VERY differently from how your existing BASIC code implemented it.

Brian_TheLion wrote:

Someone suggested that I should look at instances of classes

You create instances of classes all the time. Every time you "new up" a class. For example:

IInventory playerInventory = new InventoryManager();

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

[jschell]

As a note. If you want to learn how to create games then I would suggest finding one of the game frameworks and using that. There are adventure frameworks but others as well. Using one of those and creating a games (plural) provides a better understanding of the 'domain' for creating games. If you want to learn OO programming and you are using an adventure game as an excuse then learning the rules for the programming language (singular) is going to be your actual goal. The game itself is unlikely to be viable because without a detailed understanding of the 'domain' both from the business layer and the development layer your initial attempts will have problems with structure. And I speak from experience on that having attempted more than a couple games when I first started. But that is not a detriment because that will aid you in the future as you will understand intrinsically why something doesn't work versus because someone told you that.

[Mycroft Holmes]

Brian_TheLion wrote:

I'm looking for is a way to use this programming language that suits my needs

And there is another large problem. You are basing you "needs" on a legacy system written in basic and hoping to convert it to a modern language and development style. You should really accept that you are up for a rewrite. Look only at the functionality of the original game NOT the code that does the work in basic. If you are going to use a modern OOP language you will need to understand OOP principles BEFORE you begin trying to design the application.

Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP

[Brian_TheLion]

Hi Dave. I was thinking of breaking up the code so that all get drop actions was handled by a GetDrop class, are you suggesting that I should have the get and drop procedures in the main() class? Brian

[Brian_TheLion]

Thanks Luc for your reply. In the adventure there is a test each time the player enters commands so if the player enters get slippers the program would check if there was a test to pass first before the slippers could be picked up. The test class has 10 to 14 variables which are counters, flags, location of object, etc. so there is a lot involved in this text adventure game. I think you are suggesting that I have get and drop methods in the main() class rather than in the GetDrop class, is this would you were meaning? So far apart from the GetDrop class I have classes for Inventory, Look (or examine), Movement, Tests and SaveLoad (which might be separate Save and Load classes. The whole program could be written in the Main() class using procedures but I wanted to try creating classes as I wanted code that is in what I call black boxes away from the main code. Also wanted to try using classes to break up the code and make it easier to modify later on as well as learn about the use of classes. I have been reading books and studying examples on C#. Brian

[Brian_TheLion]

Hi Dave I wrote: It also makes the program easier to deal with when changes are made. You replied: Actually, this isn't true. You have code all over the place that can manipulate "global" variables and debugging problems with that code can be a nightmare because there is no central repository controlling access to those variables. One of my original reasons for using classes was to put things into what I call 'black boxes'. Once the code was working in the class then I could forget about the class. I send data to the class and it sends me back data. I don't need to know what goes on in the class (black box). It's like turn on a TV and getting a picture. I don't need to know what goes on inside the TV to give me a picture. If I need to make some improvements to the inventory then I only need to deal with the code in the inventory class. Brian

[Brian_TheLion]

Hi Mycroft. I'm doing my best to try and understand OOP from reading and studying examples. The code that was originally written in BASiC Will be pulled apart and put to geather so that it works under the more modern C# structure, so it is like you say a rewrite. I have a good knowledge of how the code works to do a rewrite. Brian

[Brian_TheLion]

I agree with you Dave as I tried a few years ago to convert the Basic code program into Visual Basic code. I now have a good idea of how the code works so I don't need to copy the original code but will do a rewrite that fits into the structure of C#. It seems that programs like C# make for a better programmer as you don't have the lazy ways of writing code like spaghetti with all its goto commands. The like the structure approach of languages like C#. Maybe the next thing I need to do is to work out all classes I need and what code will be as methods in the main() class. I could write all of the code in the Main() class but in doing so I would gain any experience about using classes and the advanages of using classes. Brian

[Luc Pattyn]

No! GetDrop is not a noun, it is two verbs, it cannot possibly be a candidate for a class. There is no main() class in my world; besides, class names use TitleCase and no parentheses. If Slippers can be gotten, they need a Get() method. If Keys can be gotten, they need a Get() method. Where are the slippers? where are the keys? does the adventurer know? No. Do all the rooms know? No. The slippers and the keys know where they are, it is information that pertains to them, and to nothing elxe. There should be an Inventory object (or even one per Adventurer), and everything inside such Inventory should derive from InventoryItem, which can hold common properties and/or common methods of gettable objects. An item's location would be an obvious property of InventoryItem; and maybe your complex test belongs there, so you don't have to repeat such test code in every single inventory item's code. Inside InventoryItem class, you probably will have good use for a static List where all items get stored, so you can search them. That is how a Room can figure what is present at any point in time. This was my last technical contribution to this topic. From all you write (and all you apparently don't pick up reading our answers) it is very clear to me you are still missing the basics of OOP. If you don't work on this (shut down your computer and go read one or two OOP books now!) you are wasting your and our time. Books tend to present their subject in a structured way, dealing with way more aspects than you are thinking of right now; random questions in a forum can't match that, they become useful after you acquired the foundation, not before. Good luck. Over and out. :java:

Luc Pattyn [My Articles] Nil Volentibus Arduum

[Dave Kreskowiak]

I'm not suggesting anything at all. BUt I am saying you don't need a "GetDrop" class for anything. Again, classes are always nouns, not verbs.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

[Brian_TheLion]

Thanks Griff. I like the way you use examples. The reason why I was thinking of having an inventory class was to keep track of objects that the player picked up, like the trousers that keeps a wallet and other things. If the player drops an object then the object is removed from the player and appears in the current room. There would be a limit of either the number of objects the player can carry or the maximum weight the player could carry which would be handled by the inventory class. If the player picks up gold then the inventory class would increase the players score. Some objects can't be picked up such as a building, water, etc so the inventory class would need to check if the object is moveable. Also the inventory class checks to see if the player is already has the item to be picked up. What I wanted to ask you if this is a good reason to have an inventory class? It tends to separate the code away from the main() class code. Brian

[Brian_TheLion]

Hi #realUSOP. I agree that in using Global variables is a lazy approach and does not make a good programmer. The reason why I had a need to use Global variables was so classes could get variable information from each other. The inventory class would check the objects class to find out if the object location was in the same room as the player for the player to be able to pick up the object. I'm thinking of classes grouping code together but after reading my replies maybe this is not the case. Brian

[Mycroft Holmes]

Brian_TheLion wrote:

Will be pulled apart and put to geather so that it works under the more modern C# structure

It feels like your thinking is incorrect, don't consider pulling the old code apart and restructuring it. Only inspect the code to help you define the functionality of the application NOT how it should be put together. Seriously do not try and apply basic methodology and structures to c#, everything is now an object with properties and methods. Define your objects...

Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP

[Brian_TheLion]

Hi Luc. One thing I did learn from reading your text and texts from some others is that the name of a class needs a noun word. I had thought that you could call the class any name. Strangely that is not taught in the books I have been reading (or I missed it). Thanks for your information, it was not a wasted effect. Brian