OO Design Question...
I've written some objects before but never a completely OO program. This
will be my first stab. I'm in the analysis and design stage. The program
itself is pretty simple. Basically, it reads data from a few text files
created by some other program and then imports the data into an existing
Excel spreadsheet. The text file has an unknown number of records. Each
record has the following columns:
So far, I'm planning to create an object to represent each file. And then
a collection of child objects to represent each record within the each file.
Assuming this is OK, I'm wondering how to implement the amount 1 - 5 fields.
As you can see, these are repeated fields. What is the proper OO technique
to represent repeated fields? I can think of three ways to implement this:
A) Create a separate property for each amount:
Private Property Get Amount1 As Currency
Private Property Get Amount2 As Currency
Private Property Get Amount3 As Currency
B) Create an array of amounts:
Private Property Get Amount() As Currency()
C) Create a collection of amounts:
Private Property Get Amount() As Collection
Which is the correct OO way of doing this? BTW, these property(s) will be
read only and FWIW I've been guaranteed that the file format will not change.
Re: OO Design?
Todd W wrote in message <firstname.lastname@example.org>...
>OO Design Question...
>Which is the correct OO way of doing this? BTW, these property(s) will be
>read only and FWIW I've been guaranteed that the file format will not
How do you feel about the possiblities of the file format changing in the
future? If you believe that it won't, then I'd just go ahead and use the
five distinct properties; kludgy, yeah, but quick, and it sidesteps some
issues (what happens if this record only has four amounts in its
collection?, etc). If you have the slightest glimmer that it's going to
change down the line, though, I'd use a collection (as I find them easier to
work with, and the code to be more readable, than arrays)
Re: OO Design?
To be frank, the scenario you outlined doesn't really need the level of OO
you're proposing. Consider using a single object to represent the file and
have it behave more like a recordset. Another possibility is a single
object that will perform the transform.
As far as the Amount fields are concerned I would use:-
Private Property Get Amount(Index as Long) as Currency
Secta Group Ltd
Re: OO Design?
The OO methodology is currently the best one we have in the industry for
writing programs; HOWEVER, on occasion you should forego OO for old-style
structured coding. Why?
Classes are great. You design them to be flexible and reusable. Designing
your classes with this in mind adds a little overhead to the design process--the
extra thought is good overhead, really--but sometimes the solution you need
is a quick and easy one and "structured" is the way to go. For simple, one-fuction
programs which are not likely to grow, consider structured.
As for your question: I think using a collection is more suitable for objects.
Mario T. Lanza
Metro Information Systems
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL