Mike Peters

Ranch Hand
+ Follow
since Oct 10, 2009
Mike likes ...
Debian Eclipse IDE Java
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Peters

From your question I find it hard to give a useful response, but maybe the following link may help you: response time limits
8 years ago
ArrayList is not thread safe; that might be your problem. Try to replace the ArrayList with a Vector.
Hey the game is cool, nice job! I didn't look into your questions, but at some times the game doesn't respond for a few seconds. It's still a cool game though.
8 years ago
I think the following books are quite good:
- Mastering the requirements process (isbn 0321419499)
- Writing effective use cases (isbn 0201702258)
Maybe a bit off topic, but you may want to take a look at inform (http://www.inform-fiction.org/I7/Welcome.html). I think it is pretty easy and has a lot of features to create this kind of adventure.
8 years ago
For a balanced tree the depth of the tree is log2(N) you don't need an algorithm for that. For an non-balanced tree the depth is between log2(N) and N. You can only calculate this with an O(N) algorithm if your data structure does not contain any additional depth information.
8 years ago
If performance is most important and you don't need transaction control, querying and such, then a simple file format will probably be the fastest.
8 years ago
Just a wild guess. Maybe you should listen to the key pressed event instead of the key typed event.
8 years ago

Good suggestion, but I would definitely like to have a "User" object and "User Registration". In fact, that is the first part I am trying to tackle because it is the basis for nearly any interactive website (e.g. E-commerce, User Group, Email, etc.)



It is pretty advanced to create a secure web site, but assuming you have SSL for a connection you may use a user-id and password as a token. But you will still need the session information to track a specific session. Encrypt or hash the user-id and password to prevent abuse on the client side.

For registration I suggest you create a registration view and for logging in a authentication view. The registration view takes user information and stores it into a data store. The authentication view identifies the specified user-id and password and returns a token representing the user. The token is used in every other view from then on (store it in the session information).

What tool did you use to make that diagram?



I used argouml.

What exactly are the "views"?



A view is an HTML page, JSP page or servlet (depends on the platform you're working on).

What are your thoughts on the Class/object examples I mentioned above?



you don't need to give the user a state. Use it as a token and store it in the session information. If a token is there, then the user is authenticated. that's enough state.

Also, if I had a "User" object and formal "User Registration" how would that change your diagram?





For example, "Authentication"/"LogIn" seems like a logical class to me.

LogIn{
-email
-password

-authenticate()
}

Maybe you would pass in a "User" object into the "LogIn" object and it would authenticate the User based on his/her credentials and then change the status of "User" from "LoggedOut" to "LoggedIn".

That doesn't sound too procedural to me, now is it?

So is my example and thought-process proper OOP for the Log-In Process??



Yes.

In grossly simple terms, this is what I want/need...

If John Q. Public visits our website, he should be able to...
- Browse Products
- Add Products to a Shopping Cart
- Register (required to Checkout)
- Log-In (required to Checkout)

- Start the Checkout Process...
- Enter Billing and Shipping Addresses
- Choose a Shipping Option
- Enter Payment Details
- Review & Place Order

If I can model that in a respectable OO way I would be titillated!!

Sure, there is a lot more I need to focus on, but *that* is the crux of an E-commerce site. (And if I can get that much designed and built using solid OOP, then the other things I'll need to do won't be much harder.) Also, things like a Catalog can be static HTML in the beginning since we may only have a few doxen things to sell.



Maybe for your first version you don't need user registration. That will make things a lot easier. You can use the user session to track the contents of the shopping cart and state of a process.

I would model your case something like this (simplified) and implement the views with servlets:


You the classes: User, Address Book (collection of Addresses), Address, Wish List (collection of Products), Products, Catalog (collection of Products), Shopping Cart (collection of Products), Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment), Payment.

These classes seems fine (except for the plural form in some cases) for a shopping application, so in my opinion I advice you to stick with that.



I mean use Address instead of Addresses, Product instead of Products, etc.


For example, "Authentication"/"LogIn" seems like a logical class to me.

LogIn{
-email
-password

-authenticate()
}

Maybe you would pass in a "User" object into the "LogIn" object and it would authenticate the User based on his/her credentials and then change the status of "User" from "LoggedOut" to "LoggedIn".

That doesn't sound too procedural to me, now is it?



That is not procedural indeed.
In a pure object oriented sense you don't need things that are called services. I think you should design your model based on the application's context. It is hard to tell what classes are good in your situation because I don't know the exact context for your application.

You define the classes: User, Address Book (collection of Addresses), Address, Wish List (collection of Products), Products, Catalog (collection of Products), Shopping Cart (collection of Products), Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment), Payment.

These classes seems fine (except for the plural form in some cases) for a shopping application, so in my opinion I advice you to stick with that.

The point where services kick is in the technical implementation. For example if you decide to create a multi tier application you need to design how each tier communicates with another tier. Normally a client then uses services to communicate with an application server and an application server uses a persistence interface (e.g. JDBC) to communicate with the data server.

Be very careful though with services when you implement them. If you have a procedural background it is easy to implement a service with procedural code, which you should try not to do. Try to look at a service pure as a communication channel between two object oriented models which represent one model as a whole.

Maybe the Java Pet Store blueprint implementation is a good place to start for you.
If you have a new requirement about the communication protocol then I suggest you check with the person who stated that requirement because my guess is that the person also has requirements about which standards to use. There is probably an underlying reason for this requirement, you should try to get to that.
8 years ago
I own "Developing games in Java" by David Brackeen and I think it's good for beginners who want to write action games. ISBN: 1592730051.
8 years ago