Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Hi object dudes! Sorry for the delay, it’s been a busy few months recently.
Anyway, lets find out what you’re going to learn in this part:
– Objects in the real world
– Building your program around a model
– The customer database app model
Yes, this week we will start our own mini database application using the cheesy, over used concept of a customer database application!
Lets get started…
OK. In the previous two articles we’ve talked about what objects are, and even done a little demo – but where do objects fit in to our everyday programming lives? How about some more examples!
Well, just think ahead a little. Perhaps at the moment you’re just programming in VB for a hobby, maybe even hoping to earn a little money from it. Or perhaps it’s your full time job and youre constantly having to write code for a variety of different applications. If you’re the former of the two then you won’t realise quite the importance of code reusability.
When you start to do more programming, and you have deadlines to meet you are no doubt going to want to refer back to some code you have already written and copy it over. Unfortunately you can waste a lot of time copying code from a command button, putting it into a procedure and setting up parameters. The best time to do this is at the beginning when you first write your code.
In this way you can easily reuse your code and save time when programming later. So when you begin to design (or code) your application, think in terms of objects and writing your code in nice, easy to use procedures.
Coming back to real world examples, think of MS Word. Microsoft Word (and in fact the whole of MS Office) provides a HUGE object model, which, at first look, looks very bad. But when you start working with it and delving into its properties it is actually quite good.
Now although your program may not be destined for worldwide distribution such as Word, having a well-defined object model will allow you to reap the benefits later on. It’s rather like building a house. If you start off with a good design and lay good foundations, then your house has a good base. But if you just run off and get going, the chances are that it will go wrong.
The moral of this story is, plan ahead and plan in an object model that will allow you to use the parts of your program later on. See, it all makes good sense when well explained!
OK. I think that you get the point now. Lets move on to some practical advice for building your program around an object model…
Right. Now that Ive given you a lecture on the ideas behind an object model, I’ll give you some tips for building your program around a model.
Firstly, use VB’s built in tools! There’s no point having a rich design environment if you don’t use it to the full. Visual Basic includes a very good tool for helping you deal with class modules. The VB Class Builder Wizard is what you want to be using, and it’s really very good. To load it up click Project, Add Class Module and select VB Class Builder.
You’ll see from the file menu that you can either create a new class module or collection. Now think of it like this: you use a new class module for an individual user, and a collection for a group of users. So say your class is called User then you can make a collection class called Users.
This follows a logical pattern that is also seen in most modern applications. What I would suggest you do now is to carry out what Ive described and get used to using the Class Builder.
But don’t worry; I’m not going to leave you to build your own object model just yet! Here are a few more tips.
Building your object model should be about thinking out what you program does, and breaking it down into logical parts. Think about a customer database. You’re going to have customers, and each customer is going to have a pre-defined set of properties, such as name, address etc.
Going back to the idea of collections, look at what Ive just said. There are customer(s) and a customer. Here we can see that the plural of customer will be our collection, and the individual item will be our customer. So when you think about it, you can see the obvious areas that can be broken down into collections and individual items.
If you’re having problems thinking about these things, then it highlights problems in your application design. If we carry this out at the beginning when planning our program, we will be able to prevent the failure of our project.
So planning out your object model will help you write reusable code, help other developers to use your program, clarify your application plan and even make the coffee (well, maybe not yet, but thats the topic of my next article!)
Hopefully by now I’ve bored you stiff with enough information to make you actually plan out your object model. But as always, an example helps. So lets have one then!
OK. So here we are. Ready to start out first project with an object model. I suppose you’ve got VB open already and are scanning through the page looking for the first signs of code. Well, here comes the surprise – before we do any coding whatsoever we are going to spend quite a bit of time PLANNING our object model.
Yes, the hated word planning that every amateur programmer runs away from – I can tell you from raw experience planning really does help. When I first started programming, I was diving head first into projects trying to get as much coding done as I could before I got fed up with the project.
This application had a great deal of promise, and in fact works reasonably well at the moment (despite the number of bugs I keep hearing about!) Anyway, I ran off with that and went straight into coding. Now the project has died somewhat, and I’ve no chance of reviving the project unless I take on rewriting the whole thing.
Anyway, getting to the point (at last!) – planning really does pay off. However much you may be good at designing on the fly; such as building your objects and defining the main entities in your program there will always be things that you come across that you hadn’t thought about. Going through before hand and writing down what you’re going to do will help you see these things more clearly.
So, as I finally get onto the whole point of this part, the planning of our customer database model. Firstly, we’re going to have a variety of objects. Think about a customer; that’s one to start off with. A customer is an entity in itself, and therefore we should have an object to deal with that entity.
Secondly, lets think about the ways in which a customer will relate with other entities. Well a customer is going to have a contact within your company that will allow it to negotiate and communicate with your company. So we should create a Contact object to deal with that link.
No doubt there are other ways in which these entities interact with others, but for now, we are going to simply use that structure to begin our example.
Now that we’ve defined the main entities, lets look at what properties each one is going to have.
Customer Object:
Name – Obviously each customer is going to have a name.
Here are several more obvious ones:
Address
Phone Number
Fax Number
Web Site
Email Address
Now, we need to link a customer to a contact in our company. Thinking about it, we’re only likely to have one customer connected to one contact, but our contact may handle several different customers. In database terms, we would say that the customers have a ‘many to one’ relationship with a contact.
Simply put, this means that we will have several customers related to one contact.
Due to this, the customer object will need to have an individual id to allow us to distinguish between customers. This also means that our contact will need an id to link the two together, but we’ll get to that when we move onto the contact object.
So now we’ve got a new property, a customer id. If we think about a database, this will simply be a field that increments when a new record is added, ensuring that it is a unique number.
Here’s a quick list of the properties under the customer object:
Customer Object:
ID
Name
Address
Phone Number
Fax Number
Web Site
Email Address
You’ll notice that Ive put the id at the top. This is customary when dealing with a database table, as you will see in future parts when we build this application.
From what I discussed before, we need a way to link a customer to a contact. This can simply be achieved by adding a contactid field in which we store the id of the contact that allows us to link a customer to a contact without typing out all of the contact’s details several times over. I’ll talk more about this in a bit.
Now, onto the contact object. Here are the obvious ones first:
Contact Object:
Name
Address
Phone Number
Email Address
Our contact will also need an id, so we’ll add that as well. I bet you’re wondering why the contact’s address is there? The customer isn’t going to want it (unless they completely screw up the project!) so why is it in the list? Well, simply because your company will need to keep this kind of information about someone in your company, and rather than have the same data kept in two places, we might as well keep it with the other information. This procedure is known as ‘normalisation’ in that we prevent data from being duplicated across a database.
As I said before, we don’t really want the customer to know their contact’s address, so we’ll have to keep that in mind as a business rule when we come to writing code.
That’s about it really. So here’s the final list:
Contact Object:
ID
Name
Address
Phone Number
Email Address
So, we’re now ready with our model! Unfortunately, you’re going to have to wait for the next part of this series to find out about our objects, databases, business rules and more complicated bits and bobs!
Until then, let me know how I’m doing by clicking the Post Feedback Now link at the bottom of any of the pages in this article.
Until next time – keep hacking!
