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.
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.
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:I think you want both.
Tadili Saad wrote:Hi,
I'm trying to model a system for e-procurement (request for buying goods, purchase orders, receiving and invoice verification).
I'm in the middle of drawing the use cases. I have drawn my primary use cases and I'm refining the first one.
The first use case is about this statement :
A person in the company is a member of a team that execute projects. For the execution of a specific project that person need to buy a specific amount of goods. To be able to do that they select in the application one or several items from a catalog referencing products and suppliers. They select all the products they need and insert them into a request. The request has to be validated by a supervisor before it is sent to the buyings department. The validation information is present in the project management system (which is external to the application I'm supposed to make).
This is the use case I came with
Can anyone correct me if I'm wrong.
Thank you.