Mike Peters
Mike Peters wrote:I think you want both.
Mike Peters
Jimmy Clark wrote:Object-oriented software systems consists of models of data and models of process /workflow / behavior. The concept of an "object" is a design concept layered over the core programming structures which are common in all computing languages. Object-oriented design skills are very complex and it typically will take 2 to 3 years to become a proficient OO designer.
Tom, maybe you can hire a consultant to help you with your business if there are pressing needs. Running a business and writing code for a website are different activities...you only have so much time in a day, so focusing on what matters most makes the most sense in my opinion.
Mike Peters wrote: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 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.
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?
Mike Peters
Mike Peters wrote: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.
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?
That is not procedural indeed.
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??
Mike Peters
Tom Tees wrote:
When you are building a system from scratch, do you tend to model Physical Things or instead Business Processes?
I'm thinking about a new battle cry. Maybe "Not in the face! Not in the face!" Any thoughts tiny ad?
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|