Tom Tees

Greenhorn
+ Follow
since Oct 22, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tom Tees

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.



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{
-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.



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


TomTees

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.



Well, I am just trying to build your basic, plain-vanilla E-commerce site. (Read, not Amazon.com at this point!)

Not sure what information you need to help, but just let me know and I will try my best to provide it.

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.

I think I have a pretty solid understanding from a "Business Level/Layer" what needs to be done, but writing things out in respectable OOP is another story!

Anyways, I can answer any questions you have for me.


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.



Okay, good.

BTW, can you explain more about the "plural form" thing?


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.



Well, a few things here...

1.) I'd like help coming up with a platform-independent OOD because I likely won't be doing any fancy Java stuff the first go round.

2.) I used the term "Service" because I picked it up somewhere online and that leads into one of my big areas of uncertainty. See, for me, I see things like "UserRegistration", "Authentication", "Checkout", etc as logical classes. (Textbooks get all caught up on "nouns" and "physical things", but I've also seen things like "behaviors" (e.g. Quackable and Flyable for a Duck) and "processes" (e.g. "Book a Flight", "Make an Appointment", "Schedule a Court Date") that are modeled as classes.


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.



Well, that is one big area that I need help - as you can see above.

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?


Maybe the Java Pet Store blueprint implementation is a good place to start for you.



Possibly, although I'm kind of burned out on reading examples. The reason I came here is to get some direct help on direct problems. (I've read lots of books, but I think I am ready to just jump into a my real-life problem and put away the theory if you follow?!)

Thanks,



TomTees

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.



I appreciate the complexity of OOP, but like most things, I'd like to take a layered approach. I don't need to become a guru overnight, but I would like to get to a point of where my code doesn't look like a train-wreck.


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.



I am unemployed. If I had $$$ to hire a consultant I wouldn't be here! (Come to think of it, if I could get a job in my own country (USA) and make a decent living, I probably wouldn't be trying to break away from Corporate America and start my own business!!)

Hopefully I can get some good advice and guidance here...

Thanks,


TomTees

Mike Peters wrote:I think you want both.



A man of few words.

Care to flesh that out a bit more and ive me some examples of good class choices?

What about some of the things I listed?

(I tend to favor the "processes" or "services" more, maybe because of my procedural programming background.)


TomTees
Hi all. My wife and I are trying to building an online business selling things, and I am in charge of building the e-commerce site.

I am fairly new to Object-Oriented Programming and the more I study the more confused I get?!

There seem to be a million ways to approach things, and I really haven't found any good guides. (Most books and tutorials focus on dry examples and at a very granular level. I have yet to find a source that discuss things from an Architect's perspective?!)

Anyhow...

When you are building a system from scratch, do you tend to model Physical Things or instead Business Processes?

For example, here are two different approaches to modeling our e-commerce site...

Physical-oriented approach:
- 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
and so on...

Process-oriented approach:
- User
- RegistrationService
- AuthenticationService
- ShoppingService
- CheckoutService
- ReturnService
- UserProfileService
and so on...

A couple of people have said that the first approach is a bad idea because it just mimics the database. They say, "Model things like you do them in real-life and let the database worry about how it stores things."

Other people seem to feel that having a one-to-one mapping between Physical Things (often Database Tables) and Classes is just fine.

Who knows? Maybe you need both approaches?!

Obviously there are many ways to do things, but I bet there are a couple of "architectural designs" that work the best.

If you were building an e-comemrce site from scratch, what architectural design approach would you take when designing Classes?

Some expert help is definitely needed!

Sincerely,


TomTees

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.



Some more thoughts...

What about "Catalog"??

Where is your "Buying Dept"??

Also, make sure you are modeling "Actors" and not People or Job Titles.



TomTees


Looks pretty good, but your Project Mgt System (or whatever) is an Actor to your primary Use-Case, right?

Also, I personally avoid <<included>> Use-Cases because it often leads people into "functional decomposition", although your use looks okay.


TomTees

Hi, this is Tom and this is my first post on here so be gentle!!

I am trying to learn Object-Oriented Programming - the *right* way - and am struggling to take boring textbook examples and actually apply OOP to the real-world!

It seems to me that a lot of tutorials and people online just dump a whole bunch of procedural code inside of of few Classes and call that OOP?! But that doesn't seem like much of an improvement over, say, 1980's BASIC?!

So my first question deals with what is the best way to model "business processes" in OOP?

Most examples online just create a gigantic Class with dozens of Methods, but that seems like an over simplification of how the real-world works.

For example, here are some "business processes" in real-life...
- File an Insurance Claim
- Book an Airline Reservation
- Register with Online Forum
- Transfer Funds between Accounts
- Change Deductible Amount
- File Initial Unemployment Claim

Each of those random examples would likely involve many steps and even deal with other Objects, so I don't think making any of them a single Method in a single Class would be a good idea unless you want spaghetti code?!

I have seen a few people turn "business process" into what they called a SERVICE, but I would be curious to hear other people's opinions on this.

And after some people respond, maybe I can talk more about the website I'm building and my thoughts on what Classes to create?

Sincerely,



TomTees