• Post Reply Bookmark Topic Watch Topic
  • New Topic

Custom Classes, Alternate Constructors (and the use of them in other classes)  RSS feed

 
Zachary House
Greenhorn
Posts: 18
C++ Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, I haven't quite grasped the concept of constructors yet. I am trying to create a bunch of custom classes that interact with each other using alternate constructors and custom objects. For example, say I am creating a text adventure game, and I want to create custom classes for Rooms, Creatures (to be inside select rooms), items (to be found in those rooms), and Exits (the links between each room), as well as a World class that holds the starting and ending Rooms. In fact, this is exactly what I'm doing.
So, I want to create a Room object with the identifier startingRoom that takes 2 Strings, an Exit object, an Item object, and a Creature object as its parameters. However, I don't quite know how to create alternate constructors for the Exit, Item, or Creature classes.
Now these 3 objects also take parameters, and it would be easier to show you the code.


Now, I can also post the other classes and their contents if that would help. I just need to know how to:
- Create custom objects according to what class the object belongs to
- Call those objects and use them in the creation of a Room object

Also, if you guys could refer me to any existing posts, since I was unable to find any that solve this particular problem, that would be awesome.
 
Zachary House
Greenhorn
Posts: 18
C++ Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
*Edit*

The reason I am posting this is because the startingRoom (constructor?) keeps expecting a return statement.

Also, the creature variable instantiated early in this section of code should have had the identifier exampleCreature, as well as the line referencing it inside of startingRoom.
 
Carey Brown
Saloon Keeper
Posts: 3253
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A constructor would look like
see, no returning type and name is the same as the class name.

You have defined a method called  "startingRoom" that returns a "Room".
 
Liutauras Vilda
Marshal
Posts: 4805
330
BSD
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider having Inventory class, which would have list of items List<Item>. That way you wouldn't over-complicate Room class.
In Inventory class you could create some methods to get particular item/-s. So in Room class you could have something similar to:
You can have Inventory within constructor.. But my main point was, to have Room concise.
 
Zachary House
Greenhorn
Posts: 18
C++ Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, I was hesitant about posting this topic, but the replies here are immensely helpful! I will make changes to my code for the constructor and hopefully I can get the inventory suggestion to work because that will make a huge difference in the difficulty of this project!
 
Campbell Ritchie
Marshal
Posts: 56221
171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Odd place to find this, but search for how to write documentation comments for the javadoc tool and scroll down to where it tells you about default constructors, and says you shouldn't have them at all. That means you shou‍ld always wrtiie a constructor. Go through the Java® Language Specification and it will tell you a special use for a private constructor.
I think they are right: always write a constructor, and make sure that all fields are initialised to something sensible by the time the constructor completes. I would write Liutauras' constructor slightly differently:-Now the inventory isn't null; you have initialised it to an empty List. If you try to print an empty List with System.out.println(myList); you get []
 
Liutauras Vilda
Marshal
Posts: 4805
330
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If that would have been List<Inventory>, that would make a lot sense. But mine idea was to have an Inventory, singular instance, and within that, there would have been a List of Items.

@OP
That is basically for you to decide how you are going to design your project. Try one, try another and see which one makes most sense to you.

I might was wrong in mine suggestion, didn't think a lot, just dropped some ideas which might will make you think it through if your current approach is good enough. Try Campbell's too, see how goes with it.

 
Campbell Ritchie
Marshal
Posts: 56221
171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Liutauras Vilda wrote:. . . mine idea was to have an Inventory . . .
If I have misread your post, obviously the solution will be slightly different. I probably did misread you.

But, Zachary House, the principles are exactly what Liutauras has said: work out what you want your inventory to do and design the code accordingly.
 
Liutauras Vilda
Marshal
Posts: 4805
330
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Odd place to find this, but search for how to write documentation... That means you shou‍ld always wrtiie a constructor.

The idea behind that I think is, that you should have the javadoc comment for constructor always, but if you don't have explicit constructor, where are you going to write comment?  
 
Junilu Lacar
Sheriff
Posts: 11435
176
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have seen this approach fail over and over again. When you start by thinking up a bunch of classes, your tendency is to make everything a class. This is often unnecessary and tends to complicate matters prematurely and muddy the waters before you even have a chance to clarify the relationships between all these objects/classes.

An alternative approach that has worked much better for me is NOT to start with a whole mess of classes that I think might be involved in doing a bunch of related things but instead start with one task or behavior that I want to see in the system. Then I think of what classes/objects might be involved in doing that, always keeping in mind the Four Rules for Simple Design, in particular, the one that says "Keep things small".

For example, I can start by saying "I'd like to set up two adjacent rooms to put into my game world."  Then I'd ask questions like, "What objects would I need to represent these rooms? How do I make them 'adjacent' to each other? What would the code look like if I were to move from one room to another? How do I track which room I'm in? Who exactly is 'I' here that is being moved around and tracked?"

Object-oriented programming is mainly about behaviors and relationships between things that exhibit behaviors. This is the focus I take when exploring various design alternatives. And remember, your first design choices are hardly ever the right ones.  You have to see what doesn't work to help you discover what does.
 
Junilu Lacar
Sheriff
Posts: 11435
176
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And always keep semantics in mind.  Looking at your code, I don't get what kind of semantics you'd end up with when you define a startingRoom method in a Room class. What would the code look like that uses a Room object and calls its startingRoom method?

What does that even mean? What idea is this code trying to convey? It makes no sense to me.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!