when to use collections

[tusanesen]

I m new to OOP.. I dont have much time to get experienced much and trying to implement what I ve read from the articles and some chapters abt OOD .. coming to the point :
assume I have a Stock object and I will need to show stock lists in many places of my program to the user. what I m in hesitate is whether I should have a stockList thats implementing a collection type class.. it seems I just need a method returning a dataTable in my stock class..and it will be enough to create a stock object from the ID when user select a row on the grid.. Do u have a suggestion , should I have collection class in these situations . thanks in advance .

 

[chiph]

It's a design issue. Typically, you wouldn't want something like a DataTable object being used in the presentation layer of an application. It adds a lot of dependencies on the data libraries, and compresses an n-tier application to a 2-tier app, which means you lose scalability and throughput.

So, ideally, your data layer presents a strongly-typed collection class (or generic) to callers that reside above it in the application layer stack.

If you're worried about the time to write all the collection classes, there are probably code generators available for your language to help you in this task.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[cpjust]

OK, I remember learning about the OSI model in my network classes about 9 years ago, but I've never applied it to any programs I've written (not that I've written many network related programs anyways).

If you don't mind elaborating a bit on what it means to put the DataTable in the Presentation Layer vs. Application Layer?

Also, I didn't understand this:

It adds a lot of dependencies on the data libraries, and compresses an n-tier application to a 2-tier app

What kind of dependencies, and what is an n-tier/2-tier application?

 

[tusanesen]

thanks chip. I understand ur abstract explanation very well but I think I need some implementation..
I have not seen any disgussion could go on till the UI level. so as a beginner I really have serious doubts whether someone have a program done with these UML steps anyway ..
let me turn to my specific question
yes "it s a design issue" .. I m just trying to see the differences than the conventional programming .. I was taking the records into a dataTable object and binding it to dataSource property of a grid.
Now I decided to write some easy maintainable code and made dataAccess classes for all SQL needed and business logic ones to ensure everything is ok according to what I talked about the job to the user .. now I need to cope with my UI things. and I m not sure which object must provide me data to populate the grid. simply a stock object must be responsible of itself I think, then I cant expect it to give me this stock list.. it seems so unnecessary job to have a stockList object just to show a list but I m thinking about this just for the sake of OOP rules. what do people do for such UI requirements.. by the way if I make a stockList class from a collection type for this, I will have to make many classes for every grid, every list in my program..
maybe I should have a ItemList abstract class with its inner IListable class to be implemented by Stock or Inventory or anything that needs to be listed? by the way I wont write an inventory control program, this is easiest sample I can think of when it comes to OOP
thanks for any comments

 

[chiph]

What kind of dependencies, and what is an n-tier/2-tier application?

By dependencies, I mean that the machine running your presentation layer now has to have the database junk installed on it. This is a problem for several reasons:
(1) This is a security flaw - the more stuff you have installed, the greater the chances of someone finding a hole and exploiting it. You should install the minimal amount of software needed to make the app work to reduce your attack surface.
(2) Your testing & support workload is greater, because now there's another thing to configure and test.
(3) Your installer is larger, because now you're shipping more components.
(4) There is a greater chance of code being duplicated.

n-tier/2-tier just means that the application is divided up into a number of layers. This is done primarily as a separation of responsibility thing (presentation layer should only worry about presentation stuff), but is also commonly done to make the application more scalable (just add another server or two). In addition, it helps during development because you can have two or more teams, each working on their own layer. They would coordinate their efforts by defining how their layers talk to each other, via a design document, and/or a programmatic interface specification.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[chiph]

I was taking the records into a dataTable object and binding it to dataSource property of a grid.

Typically, when you start talking about multi-tier applications, people don't do data binding.

But it's still possible because controls like the DataGrid have the ability to be bound to anything that implements the IList interface (such as ArrayList). So you could have a collection of widgets being returned from a business-layer component, and you'd create a new class called WidgetForDisplay which only contains the columns that need to be shown in the grid. You'd copy over the needed fields from each Widget into the corresponding WidgetForDisplay, then add that WidgetForDisplay to your local ArrayList, which, being bound to the DataGrid, just works.

I will have to make many classes for every grid, every list in my program..

Yup. That's how it's done.
You can lighten your development effort by using one of the available code generators. Or by starting with a fully-populated class which you'd use as a template, removing any properties which don't need to be shown.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[tusanesen]

last question to make sure I still have doubts whether there may be a smarter way to feed my GUI's with object collections at least for the sake of simplicity of my complete class diagram.
thank u !

 

[chiph]

If you use object collections, you lose type-safety. If you're a disciplined coder, you can probably get away with this. But if you have junior programmers working on it, you'll want the type-safety.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[cpjust]

Why would you lose type-safety?

vector<string> strArray;  // An array of strings.

 

[h0h0h0]

generics are only in java 1.5, templates for C++ and c# 2.0 - he might not have that ability. It's a good idea to create seperate collection classes for each of your types. I've created a baseline AppCollection class that had simple add, remove, search functionality and then simply extended those classes to each of my collection type instances. That made it easy to create collections anytime i needed one.

 

[chiph]

Because he said "object collections" I assumed he was using v1.1 of the framework. In v2.0, generics make all those type-safe collection problems go away.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

<n-tier/2-tier application
cpjust, this isn't precisely related to the OSI model. The fact that chiph is using the terms presentation and application is coincidence.

An "n-tier" application has basically 3 layers: Presentation, Business, and Data. Data objects handle data. Business objects encapsulate business rules. Presentation objects handle UI concerns.

Chip is saying that you don't want data objects to be in the presentation layer; rather they should go in the data layer.

When Chip talks about (and he can correct me if I'm wrong) "dependencies on the data libraries" he's basically saying that if you have to go get data directly from the place where the data is stored every time you need to show it to the user, you can run into unnecessary traffic jams. The best way to handle this is to add a "level of indirection" between the UI and the data access. This would be a data object, which would be responsible for optimal throughput of data, doing things like managing connections, making local caches, and the like. You wouldn't want to do those things redundantly for each object that had to show data.

HTH

Bob

 

[cpjust]

generics are only in java 1.5

That's exactly why I hate Java. ;-)

 

[chiph]

"dependencies on the data libraries" he's basically saying that if you have to go get data directly from the place where the data is stored every time you need to show it to the user, you can run into unnecessary traffic jams.

There is that, but what I was thinking at the time was more along the lines of simplifying your deployment. If the two (or more) layers are running on different machines, then that means that you have to install the database drivers and/or data objects on all the machines, not just the one acting as a server. This increases attack exposure, plus complicates things as your presentation developers now have to know all about using data controls as well as grids, checkboxes, html, etc.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

Good point Chip.