OO Design, Process advice 2

[SPrelewicz]

I started this thread in the Perl forum, but I thought I'd bring it over here also for further discussion:


i apologize if this is sort of semi-perl related, but I figured the best palce to come.

I'm making the step into OOP for my larger web based apps and would like some advice about how others layout their OO Perl apps. I will be using CGI::Application and all its plugins, etc.

My project now is a Sports stats/data site, back-end for entering player data game by game, front on world wide accessible displaying data. [Nothing unusual] i will be using mySQL.

So, I am confused about what to classify and things. I'll need a data layer, but where do i put that and how to let my other classes know about it. Say I have a Player class with position, name, etc...then a Basketball Player class with stats, ability to score point, get rebounds, etc. How then does the data loading/saving into the mySQL DB fit in. Are those methods in the Player class, should they be used to instantiate the object, should I have a separate DATA class I 'use' in all my other classes.

Also, in OO design, is it common to create an array of many objects at once, as in a roster of basketball player objects, and if so how does this affect performance?

Thank you in advance for your time.

http://www.flyingroman.com/_about_me

About me at Flying Roman.com lyric meaning and discussion

http://www.scottprelewicz.comScott

Prelewic, Renassance Man

 

[BobRodes]

This thread thread678-1121478 has some information you should find helpful.

<Also, in OO design, is it common to create an array of many objects at once, as in a roster of basketball player objects, and if so how does this affect performance?

Yes, it is common. Recordsets, resultsets, cursors, whatever, not to mention generic arrays, are examples of this. As for performance, that's very much dependent on the implementation. For example, on your platform, a structure might perform better than an object, since it's allocated differently. In other words, a theoretical object might well be implemented in practice as an object, but it might be implemented in another way too.

So first, look at how well-formed objects are constructed and how they interact with one another, then begin working out implementation details.

HTH

Bob

 

[grooke]

So, I am confused about what to classify and things.

Your mind, like all of us can only handle about 7 things at once. OO creates a hundred or so; it is worse than functional design. So as any of us build a model, we lose sight of the whole and we all become confused in exactly the same way.
The way around this is to analyse and build and test small distinct subsets; divide and conquer. Draw diagrams of some sort.

Say I have a Player class with position, name, etc...then a Basketball Player class with stats, ability to score point, get rebounds, etc. How then does the data loading/saving into the mySQL DB fit in. Are those methods in the Player class, should they be used to instantiate the object, should I have a separate DATA class I 'use' in all my other classes.

Your Business Domain Classes are these 'DATA classes'. You load and save these in some manner using the SQL, to corresponding data tables in the database; they never correspond one-to-one, but are usually recognisable.

Dont forget that your 'Player' has many different statistics, which will be collections of data. The player will normally be the 'owner' of the collection. Every collection MUST have one and only one 'owner' (the solid diamond in UML) If the Player is deleted, then all his personal stats are deleted. If you dont want all those stats to be deleted, then perhaps they belong to the club or the league; (when do you want them to be destroyed?)

Players must also have owners. Is that the Club? or do you want your player descriptions to still be available if that club is closed. If you haven't modelled a Club, then you need an address book, player records book or something that owns the list. At the very top, there will be one or two classes that are just owned by the system; choose them carefully.

Every collection and most business classes have only one 'owner'. Membership of other lists etc is just aggregation (open diamond in UML). These are things that still exist even if the list is deleted. If all players are registered in a league, the league owns them, but the clubs make aggregations of those players currently on their books. All players must belong to the league, but not all of them would be in club lists.

Re the 'Container Classes' (arrays, sets, maps etc. They will provide you with a lot of time-saving code, and I bet it is more efficient than any other method you might come up with; gurus may do better, but who cares. Only optimise when forced to; then employ a guru.

Gil

 

[BobRodes]

Here's my two cents' worth on aggregation vs. composition: suppose you want to model a flock of geese. You might have a flock object, associated with a number of goose objects. If the flock goes away, you still have the geese. That's aggregation.

Now, you have an apple pie object, made with 6 apples. If you get rid of the apple pie (presumably by eating it) you get rid of the apples too. That's composition.

The main difference between these is that they both represent whole/part relationships (the side with the diamond represents the whole), but there are no lifetime restrictions on the parts in aggregation, whereas in composition the lifetime of the parts is dependent on the lifetime of the whole.

There can be some confusion deciding which one is best in a real life application. Suppose, for example, you have a Car object, which is composed of numerous part objects. How you set it up would depend on how parts are used in the business context. For example, a manufacturing concern would probably use composition (the parts are forever removed from inventory as soon as they are used to build a car; as Gil says, they are used in one and only one car), but a garage repair shop would probably use aggregation (parts can be removed from a junked car and placed in inventory, or used to rebuild another car).

As for player and statistics, you can certainly set up the statistics for a player as a collection and associate it with the player. However, you can also model them as attributes of the player object, and in this particular case, I believe that's what I would try first. My feeling is that in general this would perform better. Gil, what do you think about that?

Bob

 

[SPrelewicz]

Sorry, Im a bit tight on time, but I dont want anyone to think Im ignoring the thread. It has been VERY helpful and encouraging.

More later.

 

[grooke]

What did we used to say in the days of database Entity analysis; "One man's Entity is another man's Attribute." This is always a matter of choice.

Single instance values, like personal best times should be indiividual attributes at first glance. Then a list of all the times for that event is really a list of other objects; these may be just value objects such as time, or they may be objects from a new class with attributes of Time, When, Where, Conditions etc.

But now, let us say you run in 12 different athletics events. Do you put 12 attributes in your class or do you put a list of objects that give the Personnal best time and the event type for each event.

As I say, it is never a definite situation.


Your car problem has always intrigued me.

My favourite everyday example is my Trousers. They are composed of two legs, a waist and three pockets. That is composition. My pockets contain $1 coins, a couple of security cards, a pen and a piece of chewing gum (unused). That is aggregation.

If I throw my trousers away, my wife may rescue a pocket first, to replace the one in my other trousers, but that sort of breaks the rules. Similarly, when I threw away my trousers, I left a security card in the pocket. Does that now make it a component of the trousers?

If the chewing gum is on the table by itself, is it still part of the aggregation? To me, Aggregation requires a container. Rumbaugh says " Think of it as a modelling placebo". So who is right?

Also, Composition requires ownership. Again, it is a matter for individual decision.

The hardest bit is keeping your mouth shut when your workmate uses that discretion in a way you would not have ;-)

Gil

 

[BobRodes]

Very amusing explanation! Thanks for sharing. To me, the crux of the decision lies in your "that sort of breaks the rules." That, of course, depends on what the rules are, and as we both know well, "rules" is a malleable concept.

<Does that now make it a component of the trousers?

In my opinion, it doesn't, for the same reason that shooting all the geese doesn't change them into components of the flock. Composition implies an absolute lifetime dependency, not an incidental one. In terms of implementation, the destructor of a composite object is responsible for also destroying its components, whereas in aggregation this is not the case.

Bob

 

[grooke]

Hmmm! First stir, then agree. If I have a landrover that is scrapped, are the wheels, carbureto, radiator etc a composite part of it? If the are a firmly fixed as you suggest, then I cannot change them, and when the landrover is scrapped, I cannot sell some of them for scrap.

Yes! As Martin Fowler and others say, these are somewhat matters of convenience. Your definition seems to be the best, provided I'm allow to bend the rules occasionally.

Gil

 

[BobRodes]

<If I have a landrover that is scrapped, are the wheels, carbureto, radiator etc a composite part of it?
Yes and no, of course.

<If they are a firmly fixed as you suggest...
Moi? I suggested nothing of the kind. Unless I did...

Again, it's a matter of context. I'll expand on my car example if I may: a manufacturer will view a car as having parts that are irrevocably part of the car, whereas a junkyard will view the same car as an aggregation of usable parts. If I am a scrapyard, and there are parts of a car that I can't remove and sell, then it probably doesn't make sense in that context to represent those parts separately to begin with.

To illustrate this a bit further, let's say that the junkyard doesn't pull steering columns out of the car and sell them separately. It wouldn't make sense to have a "steeringcolumn" part in the car, since abstracting that out from the car as a whole serves no useful purpose in the context of the problem domain. So, different problem domains will relate to the same real world entity in different ways, and in so doing will model it in different ways.

Bob