|
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<inventoryitem> 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 | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Hi Dave.
I have learn from yourself and from a few replies that the name of a class should be a noun.
That presents a another problem is how do I get a message back to the player from the inventory class such as a condition where it was not possible pick up an item.
I'd have a rich text message box on the form attached to a string called messages and hopefully there is a way to check for changes in the string so all I need to do is to change the text in the message string which would cause the rich text box to display the string as the string has changed.
I'll study the OnPropertyChanged() command.
Brian
|
|
|
|
|
The Inventory class isn't responsible for communicating with the user at all, nor is it responsible for picking up items.
The Inventory class just manages what is already in inventory, adding items to it, and removing items from it. Nothing else. Think of as a bag of items.
Can a bag pickup items from the room? No. The Player has to pickup the items and place them in the bag.
Forget OnPropertyChanged until you learn the basics of OOP. It's not going to help you.
|
|
|
|
|
In that case it looks like I need a Player class Dave.
Brian
|
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
I came from C++ to .Net, and I disagree. When used appropriately, global vars are a viable - and even necessary - part of C++.Simply replace the global vars with a static class that contains the vars, and you're off an running. I don't understand how this would be a bad thing, and will continue to use my static globals class for this kind of stuff...
".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
|
|
|
|
|
Is it weird that I rarely use global variables?
I've used static classes with constants defined for "magic values" and objects that are required throughout the code, like a logger, but true global variables, not really.
|
|
|
|
|
Thanks for your support realUSOP.
Brian
|
|
|
|
|
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
|
|
|
|
|
Please accept that my intention in saying this to you is positive, addressed to that vital entity in you that learns ... that develops new skills over time.
So far, I see you as having been "messing around" with C#; I see no evidence of systematic study. You continue to ask questions which ask us to "spoon-feed" you information you could easily have found for yourself.
Go ahead to C++, have your global variables, but, don't kid yourself that you have taken a serious look at C#.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Hi Bill.
I have not completely given up on C#. I was just considering C++
I have a program I want to convert to C#. I have all the variable names I'm going to use and also some of the classes I'm going to create in breaking up the code into classes.
To make myself more clearer I need to be able to do the following.
Example:
Main() class
Class A
Class B
Main() class calls for a value or a boolean response.
The result that Class A sends to the Main() class depends on a value in Class B, so Class A needs to check on value in Class B. Just before sending to Main() class the result, Class A needs to update Class B.
In C# it seems that classes have strong walls and the main communication is between the main() class and the class and not between the classes themselves.
I have been checking with various tests to see what is possible. So far I have managed to send a variable from the main() class to class A and have class A change the variable and have Class A send it back to the main() Class.
I have not found a way for Class A to read a variable from Class B or for Class A to change a variable in Class B.
Brian
|
|
|
|
|
Brian_TheLion wrote: I have a program I want to convert to C#.
And there is your problem!
You are taking an existing C++ program and assuming that the "best idea" is to translate it to C#, because C++ and C# are so similar.
But they aren't. They are completely different languages that share some common syntax. They work differently.
Ignore computers for a moment and think about languages. Write a letter to your friend in English.
You then remember that Hans doesn't speak English, only German. So what do you do? Well, they both use the same alphabet, so it can' be that hard. Grab a English-German dictionary, and look up each word in turn. You will end up with a letter full of German words - but is it a good German letter? Does it make sense? Does it say what you wrote the original to say? Almost certainly not, because the English word "Current" for example, has many different meanings: "the flow of water", "the power of electricity", "modern and trendy", "a dried grape" which will all have different words in German: "die Strömung", "der Strom", "gegenwärtig", "die Rosine". Which one did you use?
Literal translation doesn't work for languages - that's why Google translate is so incredible, it tries to work out from the whole context what you are talking about. In fact it lists many different translations for "Current":
derStrom current, power, stream, electricity, flux, river
Strömung flow, current, stream, trend, drift, tendency
aktuell current, latest, actual, topical, up, relevant
gegenwärtig present, current, existing
laufend running, ongoing, current, present, routine, runny
derzeitig current, present, prevailing, of that time
augenblicklich present, current, immediate, momentary, temporary
geltend established, current, in force, prevailing, operative
gebräuchlich common, customary, usual, conventional, current, standard
gängig common, popular, current, going, possible
bestehend existing, established, present, current, standing, prevailing
jetzig present, current
nunmehrig current, present
herrschend ruling, reigning, dominant, prevalent, prevailing, current
marktgängig marketable, merchantable, current
And it will use the appropriate one. Google Translate[^]
So ... back to computers. Why would a "literal translation" of C++ work as a C# program?
The answer is, it doesn't. C++ comes with a lot of "baggage" because it evolved from C with added OOPs and has been expanded and modified by a huge committee since then. C# was a new-from-the-ground-up language designed for object orientation (and is being modified by a huge committee so ...) which shares some common syntax.
Translating letters word by word doesn't work: you write a new letter that means the same thing.
Translating programs doesn't work: it produces bad code in the "destination" language. Instead, use the original as a specification, and rewrite the code for the new language. That way, you get good code that does the same job.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hi Griff.
First of all I'm not trying to translate C++ code to C#. I just thought that C++ might be better suited as it supports Gobal variables, but I have not abandoned C#.
The original code was written in the BASIC language back in the 1980's
I did attempt to convert it to Visual Basic some years ago and like you say it does not work when you try to convert the code exactly how it is written.
Since then having a good idea on how the BASIC code works and have wanted to convert it over to a different language but not exactly how it was originally written. The aim in using a different programming language was to get it working in it's basic state then improve on the program.
The problem seems to be in getting classes to communicate with each other in C# so that Class A gets a value from Class B (maybe some boolean condition or value is needed from Class B) in order for Class A to supply the correct info to the main() class. Class A may have to update a variable in Class B also. Can one class control another class?
Someone suggested that I should look at instances of classes so maybe the answer is there.
Brian
|
|
|
|
|
class A
{
private B _b = new B();
public int GetValue()
{
return (_b.BoolValue) ? 1 : 0;
}
public void SetValue(int input)
{
_b.BoolValue = (input != 0);
}
}
class B
{
public bool BoolValue
{
get; set;
}
}
class Program{
static Main(string[] args)
{
A a = new A();
Console.WriteLine(a.GetValue()); a.SetValue(42);
Console.WriteLine(a.GetValue()); }
}
I cannot imagine you had a look at C# without having to instantiate any class at least once. Maybe because you tried to copy some existing code which was not written with OOP in mind? You should take it from the ground, and follow some basic tutorials about C# and OOP not directly related to your task; this way you may get some important concepts that you will apply later to your actual case.
noop()
|
|
|
|
|
Thanks phil for the example code, I'll study it.
I find code examples useful in learning how C# works and can be applied to my own code.
Brian
|
|
|
|
|
The problem is that you aren't writing a C# program (German letter): you are trying to translate a VB program (English letter) into C# (German letter) by translating each line of code (using a dictionary)
Quote: You have an inventory class and a get/drop class
Why?
Do you do that in the "real world"? Or do you think "I'm wearing trousers. In this pocket I have a hanky and my small change. In this pocket I have my phone, in this one my wallet. My wallet contains my credit cards, store cards, and bank notes"?
In an object oriented design, you would have an abstract Container class (or possibly an IContainer Interface) which had Add, Remove, and List methods - because just like your trousers, they "know" where to put your phone - left pocket; wallet - back pocket; and so on. And if the Trousers class derives from Container and so does the Wallet class, you remove a card from your wallet (and it's gone from your trousers as well) pay for your sandwich, and put it back.
The idea is that the object knows how to do things that directly affect it: not that you have global functions that manipulate global objects, or a class of "actions" you can "apply" to objects.
Why should an inventory be a global variable? Is there only one in the entire game? Or should "monsters" have one as well so you can "Loot the body"? Think of Oblivion / Skyrim and loads of things have inventories: player, barrels, shops, chests, bags, boxes, bodies, npcs, ... and they are all handled the same way because they aren't globals - they are objects contained in the world.
As I said, translating doesn't produce good code - using the original as a specification does, because you then write good code in the target language. It doesn't matter which language pair you pick: blind translation isn't a good idea.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
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 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();
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
