Question on overview of C# OOP in business WinForms application - scope of Object

I may have all this OO completely wrong, but here goes:

Ok, the scenario is a classic order entry.

Customer places an Order which has OrderLineItems of StockItems. Order is entered by Employee.

1. Application starts and asks for login/password
2. Employee selects 'Orders' from Mainmenu form
3. Orders forms opens....
4. Employee selects Customer
5. Employee selects Stock adds to OrderLineItems
6. Selects second StockItem; add to OrderLineItems
7. Order is committed, (stock decremented, order posted to DB, Order printed)
8. Employee is returned to MainMenu

Now with Object scope:

1. Application starts and asks for login/password
   • Is this the best place to make objEmployee, to be kept whilst in this whole Sales application?
2. Employee selects 'Orders' from Mainmenu form
3. Orders forms opens....
   • Make objOrderHeader, is objEmployee able to be passed in or is it created here, or re-created here.
4. Employee selects Customer - adds/edits Customer details if required...
   • Make objCustomer
5. Employee selects Sto开发者_运维技巧ck adds to OrderLineItems...
   • Make objStockItem and objOrderLineItem -> add to objOrderLineItems_collection
6. Selects second StockItem; add to OrderLineItems...
   • Make objStockItem and objOrderLineItem -> add to objOrderLineItems_collection
7. Order is committed, (stock decremented, order posted to DB, Order printed, Order Entered By = EmployeeID)
   • Once posted to Db, all objects now redundant/garbage (except objEmployee?)
8. Employee is returned to MainMenu
   • Is objEmployee still valid as an object?

---

I am far from an expert, but what you are describing seems to be more a procedural idea than an object oriented one.

If you were thinking in object oriented terms you might be asking questions such as should Employee and Customer share a common Person base class that defines Name, Age and Address properties which Employee can inherit and extend by adding a Salary property and Customer could extend by adding a CreditCard property.

Maybe both your Employee and Customer business objects will implement an IStoreable interface that defines methods which are called when you want to save/load them to/from a Database.

Perhaps you would use a CustomerPresenter class that maintains a reference to a Customer object and manages the way that it is displayed by the CustomerDetailsForm for editing.

As far as object creation is concerned, I think this is something that the needs of the application dictates, but you don't want to break encapsulation by having an Employee class that is also responsible for creating Customer objects (daft example) so sometimes you will have other objects who's job it is to manage the creation of Employees and Customers at the appropriate time.