Still struggling with OOP

[DeanConsulting]

Hello all,
It has been some time since I have been on here. I have been working with learning OOP and the help that you all have given me in the past is helping. After several months of on and off playing with OOP I have decided that my biggest road block, for the moment, is not being able to describe something as a class. I just cannot seem to get my head around it. For example, here is a description of a program a client has asked me to write in the past:

I need a database that tracks real estate signs, lock boxes, and flyer boxes. I need to know which agent has taken a sign, flyer box, and/or lock box to a particular piece of property so I can update the status of the sign, lock box, and flyer box as either ("available", "missing", or "lost"). I need to be able to create reports based on the type of item, the status, the date it was placed on the property and the date it was returned to the office.

My major hangup is how to tackle this in the OOP world.

My objects, I think are: sign, lock box, flyer box, property, agent, report, and database.

I know that I would create a base class called "box" and can create instances from box for the flyer and the lock.

I also know that I need to describe each object (properties) but I am not sure what each object needs to do (methods). For example, my property object, I think, would have the following properties: id,street location, unit number,city,state. I don't know what methods need to be described here.

Beyond that, I am lost as an easter egg. Any help would be greatful. Point me to some online reading material would also be greatful.

Thanks in advance,
Noble




---------------------------------------
Noble D. Bell

http://www.noblesoftware.com

http://www.noblebell.com

 

[jaxtell]

Personally, I'd create a table for each "object" type, and then a table for each relation type. So you'd have a sign table, a lock box table, a flyer box table, a property table, an agent table, a sign-property table, a lockbox-property table, etc. depending on some set of business rules. The reports are just different queries on these tables. I'm not sure I'd refer to this as an object oriented design, but its the design I'd use.

 

[DonQuichote]

Let me give you a viewpoint that may be helpful or not.

Viewpoint: objects are employees.

Like employees in a company, objects have a specialism, with skills and responsibilities, and only report to a few colleagues. You can see the "database" as a warehouseman. His job is to provide the goods you would get from his warehouse. How he gets those things is his responsibility. He may very well delegate some of that responsibility to somebody else (a transporter, for instance). Also like employees, objects have a certain degree of independence.

So, what will go in the reports? Are the items you describe individuals (each differently marked for tracking) or "just items from a heap"? Will you ask your agent object which individual items he has taken to which piece of property? Or would you ask a "sign" object where it is? Or would you ask an "inventory" where a certain sign is? Or would you ask a "real estate property" what items is currently has?

"Report" can be a vary vague term. It may mean a list of percentages of missing, too late or wrongly placed items (as a quality check for management, for example) or the status of one real estate property (for the telephone support people, for instance)

If the lock box and the sign are nothing more than tagged items, you would not need to use different objects or tables to describe them. If one of them has extra properties or responsibilities (a maintenance interval property, for instance), the need for different objects is bigger.

Whatever you choose, you can always switch later, if the need arises. No design is perfect, and if it is perfect today, it is not perfect anymore tomorrow. I can only recommend to start simple, and add the necessary complexity as you go.