OO Theory 7

[cpalermo]

I am a complete newbie to OO, and I have limited VB experience. However, I am in the process of planning an application, and would like some advice.

The application will be tied to a SQL Server for the DB, and will be used for entering, tracking, and saving job information for a commercial print shop.

Here is my plan, and if anyone sees a problem with this thought process, let me know

I would like to have 5 classes. Customer, Job, Ink, Stock, and Press. Each class, except job will have unique properties and very few methods. Job however, will have many properties from each of the other 4 classes. I plan to have each class be a 'top-level' class, rather than a sub-class. I considered having job a sub-class of one of the others, but abandoned the idea.

As I said this is my first attempt at OO, and if I am way off here, feel free to tell me that - I'll go back and hit the books.

The plan for the app will be:

User creates new instances of ink, press, stock, or customer. These are then written to the db.

The user may also create a new instace of a job, and validation will occur to ensure that the customer, ink, press, and stock exist in the db, otherwise, the user will be prompted to add an instance of the appropriate class.

Once the job is entered, some pricing methods will occur, as well as a "job ticket" form created and printed. The job info is written to the db.

Sorry for the long post. Am I on the right track here?

TIA
Chris

 

[Foada]

Just some of my opinion . It sounds to me you are an the right track but you should ask yourself are ink, stock, and press (and maybe customer?)deserving of their own class or are they actually a part of the job? Generally you would design an "Object" do be stand alone, my point being if the ink only has a couple of properties is it really a part of its own class or just a couple of properties that really belong to the job. If you can use the Class ink in several other applications then it maybe worth its own class, otherwise include it in the job class. The whole idea of OOP is to make stand alone "Object" that can be use to build a project, but it is really easy to go over board as well. Just an example if you were looking to build a "Company" project you may build a managers class and a person class. The person class would be able to be used in the manager class as well as when the company grows the executives class.(Inheritance). It would however be impractical to make a class for first name, last name, height, eyecolor, etc etc when these classes are all actually a part of the person class. Hope this sparks some thoughts. Anything is possible, the problem is I only have one lifetime.

 

[cpalermo]

Thanks alot. This is exactly the sort of thing I was looking for. And yes, you have given me something to think about. I guess I will put it all in one class. The more I think about it, the more that makes sense.

Your advice is very much appreciated!

Chris

 

[RobCrombie]

Why are you going OO ?

I subscribe to the 'KISS' philosophy (Keep It Simple Stupid)

I think in general life, and in programming, we strive to achieve order amongst the chaos.

Bill Gates contributed greatly to the simplification of programming, when he released VBClassic ( VB6 and its predecessors ).
(I will get to VB.NOT later. <== Not a typo)

The reason VBClassic has been so popular is its ease of use.
Unfortunately developers have to solve complex business needs, so there has been the frequent problem of creating complex and error prone applications.

Much of this (problems), has been the result of sloppy programming.

So some genius decided to create OO approaches (in VB), to force developers to give up their sloppy approaches to programming.

This unfortunately breaks the 'KISS' philosophy, as you still end up with very complex programs. They may be less error prone, but it is a bugger to develop and manage all of those objects.

I believe a better approach is to develop (simple) techniques, that allow you to continue to use VBClassic, BUT PREVENTS THE SLOPPY CODING.

I believe the main goals when developing applications are -
- Manage/avoid chaos, in what otherwise would be a complex application.
- Avoid errors.
- Encapsulate your data ('Black Box') approach
- Achieve re-use of modules, forms, functions etc (mainly due to encapsulation).

Encapsulation means that your forms, procedures etc, get all of their required data passed to them, so that they need to know nothing about the Forms or procedures that called them.

ALL OF THE ABOVE IS POSSIBLE WITH VBClassic
(So you don't have to go OO mad, or worse go to VB.NET)

As I said, I have developed techniques which achieve all of the above goals, and I intend to get around to documenting them, and spread the word to those that are interested in staying loyal to VBClassic.

If anyone is interested, post a request back to this forum, and I will get to it sooner than later.

Getting back to your problem, what is the business need (or current problem), that is driving you towards the complexities of going OO ?

If your goal is only to learn OO, then you would be better served going to VB.NET now. Rob
rob@crombie.com

 

[strongm]

See this can of worms? Let's open it...

 

[muesli]

My advice is: don't go OO. I've gone both OO and non-OO and I know which is easiest. Return recordsets from stored procs when you run a query. Call stored procs to update the database. This is all you need to do. If you want to check concurrency, compare timestamps when you update via a stored proc.

I worked on an OO database application like the one you described. It was tedious to write each object's persistence code, an overall nightmare to maintain, performed like a dog and took up huge amounts of memory. If you want a good compromise, then apply the idea of 'stateless' business objects that only support methods that take parameters (so properties), and return ADO recordsets when necessary. This is what I currently do when I construct a C/S app. The performance is good, it's flexible and easy to maintain. Make life easy for yourself.

 

[CajunCenturion]

To add my 2cents worth, I consider an object as another type of data structure, albeit one with more capabilities and functionalty than traditional structures, such as a array, tree, linked list, stack, deque, queue, ...

Then I evaluate the problem and choose the data structure which best maps itself to the problem. If the object fits best, then use the object. If an array fits best, use an array.

Like Rob, the rule of KISS is extremely important, and objects should not be used simply for their own sake.

Choosing the right data structure will pay off in the long run, and grealy simplify the code, and the solution.

Analogously, you can ride a bicycle across country, and you can take a 747 to the next town over. Analyse your travel needs and choose the right vehicle.

Analyze your problem, and choose the best data structure.

Good Luck

 

[Foada]

I agree with the KISS idea as well but I think that this now has become a question of the definition of OOP and the level that you carry it to in VB. As Rob stated &quot;Encapsulate your data ('Black Box') approach&quot; but is that not a driving force of OOP? There is alot of talent in this form and I do not mean to disregard any one's opinion but like strongm stated this is &quot;a can of worms&quot;. I have worked with people that made collections of classes of ADO recordsets, that is way overkill, but I have also worked with people that have code scattered in modules that should be in a class and the next time they just re-write all their code with the same lack of organization. I guess what I am trying to say is that a good programmer can use OOP to the level needed if at all for the task at hand. There is a place and a time for everything, some projects require OOP some will not. Back to the original post though, Chris is a begining programmer that is looking for advice and trying to understand the concepts of OOP to the best that VB can, my opinion is that in order to truely see the downside of something you first have to have an idea about it. With the project he has at hand it does not sound overly complex which in my mind would be a good place to get involved in trying OOP with VB, then look back and say hey this was overkill or man this should have been a part of a class etc etc. Once again no disrespect just an opinion. Anything is possible, the problem is I only have one lifetime.

 

[wekkew]

Ok here goes my two cents....

I agree with the comments about horses for courses but even so....

rob - have you even used vb.net? You might just be surprised - it is far superior to vb6 and if you think that Microsoft will continue to support your classic vb in the future I think you're living in a dream world.

You ever tried writing windows services in VB Classic? VB5/6 gives newbies a very false impression of what programming is - they drop a few cute controls onto a form - add a few lines of code and wow - they've written an application. Never mind scope/lifetime/deployment/dependency files and the like. It practically invites sloppy programming.

How many vb programmers quit an app by the use of the keyword &quot;End&quot; - no thought given to setting things to &quot;Nothing&quot;. Not to worry though, Windows will clean up after you. Memory management is just something for others to worry about (C++ programmers methinks).

What about the benefits of the .NET framework and the CLR?
don't knock it just becuase it's new - it's a huge improvement over vb6

Kate

 

[Quehay]

Just to add one more strain of thought:

1. Model your data first. Understand what the realities of the working environment are, and explicitly codify them.

2. Determine what problems this db is going to solve and the report outputs. Explicitly codify them.

3. Develop a 2nd-3rd normal formal relational table scheme to handle the data.

4. Put business rules in tables in constraints and triggers as much as feasible.

5. Work with mockup forms and users to determine the friendliness of the app design.

This is all standard SDLC stuff (sytem development life cycle). It doesn't mean that everything works right, but it does give you a clear, agreed-upon definition and objectives.

5. Put data entry validation, error handling, etc. in modular front end code. Here having classes (connection, error handler, validation, get business dates, etc.) or bas modules will give you reusable objects and allow changing logic without having to track dependencies through tons of code sections.

 

[muesli]

Just to add a coda to my previous comment:
if you decide to use stateful objects to model database information, you are on a hiding to nothing. In every VB client server application is these is implicit state which is maintained seperately from the database. For instance, a data grid may have a set of order lines with statuses: thse will be changed in the database and somehow the client must become aware of it.
Some controls do this transparently for you (such as recordset-bound controls). Implementing a layer of stateful entity-level objects in code between the database and the display layer means that not only do you lose this advantage, you now have to synchronize state between objects, database and display, and deal with discrepancies (e.g. someone else updating a record) gracefullly. To be sure, many people have developed elegant design patterns for coping with this problem. I have worked on systems where this has been done and most of the coding effort has unproductively gone into this kind of concurrency maintenance.
Another issue which is seldom addressed is that of coupling. Entity level object definitions are hard-coded and therefore strongly coupled to the underlying database tables. This means that if you run several queries which return, say orderlines for an order, you must always return the information in a format which can be easily translated in full to a collection of meaningful Orderine objects. You lose the flexibility to pick and choose database columns at will; you have difficulty joining tables together; GROUP BY clauses become almost impossible.

Ultimately, I'd say, the criterion as to what you use depends entirely upon who your customer is. If you are providing an ActiveX control which requires a complex object hierarchy (such as a TreeView or ListView) then using a stateful object model has huge benefits. It enables your customer (the developer) to consume the services provided by your server much more efficiently and helps them maintain context when programming. However, your customer when you write a database application is the end user. none of whom, to my knowledge, have been happy with the explanation for the system being three months late is that it implements an elegant, fully OO architecture!