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.)
What tool did you use to make that diagram?
What exactly are the "views"?
What are your thoughts on the Class/object examples I mentioned above?
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{
-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??
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.
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.
For example, "Authentication"/"LogIn" seems like a logical class to me.
LogIn{
-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?