Object oriented Design 6

[SPrelewicz]

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.

Scott

http://www.flyingroman.com/_about_me

About me at Flying Roman.com lyric meaning and discussion

http://www.scottprelewicz.comScott

Prelewic, Renassance Man

 

[1DMF]

Werd up Trojan, make mine a JD, i'm a bourbon man!

Now all I gotta do it, convert that to use in standard web app/ SQL DB coding.

I can see the use in a computer game designing a character, how do I apply this logic to hmm, let me think... how about an online shopping cart.

what is the object , the users shopping basket, of class basket, basket is made up of items, each item placed in the basket is an object of class "Loaf of bread", and an object of class "Tin of Beans".

is that the same analogy ?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

Just because you can use objects doesn't mean that you should.
If you understand the basics then the objects will start to jump out at you as you design your code.
A good example is usually anything that you might want an array of but is more complex than just a single value.


Trojan.

 

[SPrelewicz]

1DMF - Thats exactly the conundrum I have, which was I guess the original intention of this thread. When you use video games, car, dog examples, it comes clear eventually, but when you have to model concepts and such, thats where i go wrong as well. Then you add layers and such.

But this thread has helped, beleive it or nt [Whats the tek-tips record for most posts in a thread?]. Trojan has been helpful. He is right about the first thing to learn is the class/object difference, but I think your confusion had to do with containing, ie a "HAS A"relationship so thats why i focused on that.

Oh, and when I type words in caps, I dont mean to sound like I yell, I do it to make that part stand out.

Okay then, TGIF!!!

 

[TrojanWarBlade]

I was involved a thread recently with nearly 200 posts in it.
So this is nowhere near yet, and many of the posts in that one were mine!


Trojan.

 

[KevinADC]

this thread has more stars than the Milky way!

 

[1DMF]

Just because you can use objects doesn't mean that you should.

ok , so when do you know, i've never had code come smack me in the chops like a wet kipper and say whoo hoo use an Object/Class, I have to dig deep for the code i produce.

When will I know, or is standard function/module linear programing all you need for basic data manipulation and number crunching.

objects and classes are for gaming and other type environments, like i use the outlook object to send emails from our Access Database via VBA.

Good old fashoined coding is what is needed when your just holding data in a shopping basket, a simple hash or array will do that for you, even a comma separated scalar string, and then use the split command, well that's all cookies are.

why use a sledge hammer to crack a walnut!




"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[SPrelewicz]

Let me tell you why i decided to take the leap with this particular project:

The App will be basically to take sports stats via an admin panel on a game by game/player by player basis. All the player info, game info, season info, etc is stored and viewed and such later.

It will be available for many different sports. Each sport is different from the next, but they all share certain similarities so I had plenty of opportunity for code reuse. that is, I could have a

PLAYER class,
and then use that as a super class for BasketballPLAYER, BaseballPLAYER, FootballPlayer, etc.

Then I could have a GAME class, and subclass that with
BasketballGAME, baseballGAME, etc..

So when part of your app can be used elsewhere, then OO may be the way to go, though you can still reuse in perl with methods, etc...

 

[SPrelewicz]

-->So when part of your app can be used elsewhere, then OO may be the way to go, though you can still reuse in perl with methods,

With OTHER method, ie Modules!

Reminds self to hit "Preview" before "Sumit

 

[TrojanWarBlade]

I guess you need to practice with some obvious things.
The old "cow goes moo" thing maybe.
When you create things like this you start to get a feeling for what it's all about.
Remember that it's simply a tool and most number crunching scripts do not use objects.


Trojan.

 

[1DMF]

if your just storing basic stats isn't this a case of just having a simple relational database ?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[SPrelewicz]

Yes, there will be a data layer, but I over simplified the specification. I will be using a DB with a data object. But theres other things to do as well. I have a Templating "object', session objects, etc. But I dont see why you cant use OO for a web app with in conjunction with relational database.

 

[1DMF]

Man i'm thoughrly enjoying this thread, I've learnt so much, and still hope to learn more.

I'd love to see how you implement this project using the OO model and PERL for your environment.

i'm sure i could understand this better with your concept SPrelewicz and help from the likes of TrojanWarBlade .

I've yet to fully understand OO let alone how you would create and object/class in PERL. Let alone use it.





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[Corwinsw]

http://www.tpj.com/documents/s=9684/sam05010002/tpj0501-0002.html

Read this. There is a type of 6months free registration, so you will need to register, but this is one the most understandable explanation of OO I have ever seen.

I have read many books and articles about OOP. I have studied it at school. I think I could understand it's main concepts. But when the time come to write something, I totally block. I just haven't ever writter sth like this and don't even know how to start.

So my suggestion is:
Let's try together write some type of a simple project. The old expierenced guys will supervise us and the newbies will try to plan the structure of the project and then write the classes.

Corwin

 

[1DMF]

I think this is a long term project, as i'm not sure OOP will help my current systems, I have learnt to write modules and where ever possible, re-use my code by way of functions.

What project would you suggest we concider to get a better handle on the OOP thing, and how you would do it in PERL.





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[Corwinsw]

No I am suggesting to make sth small, just to see how it is happening.
For example the objects in a house

Corwin

 

[1DMF]

sth small

huh? sth whats that, sorry you've lost me, well it is monday morning.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[fishiface]

Sorry I've been missing the fun here - busy weekend.

1DMF: why not give my earlier, lengthy post in this thread another read now that you're getting your head around the terminology. Some of the concepts used - "a Form object has a collection of Field objects and a collection of Decoration objects" - map very cleanly onto the sort of examples you've been using in the thread - "a Car object has a collection of Door objects and a collection of Wheel objects".

One of the problems I had learning OO programming was that all the examples were either about drawing graphics or some bizarre TV object with a current_channel property and I could never see applications in the sort of code that I write every day.

It does take a while for the real power of the OO paradigm to sink in as it requires a change of approach, a change of the way we think about applications. I started with only curiosity but I'm glad I did as I'm now getting real benefits.

One thing that no-one has mentioned so far is perltoot - Tom's OO Tutorial. Packaged with the perl manual, this quaintly-named page walks you through all the basic techniques of OO programming in perl and I refer to it frequently when stuck.

Yours,

fish

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur

 

[1DMF]

Hey fish,

I'm still confused over it's use in as you say "the programming i do every day".

I now understand its concept, and can grasp your form analogy, what i don't understand is how you would implement it.

I assume you break it down to building your own form as an object, bassed on class form, but define what object the form has. Object 'select list' of class 'select list', or object 'checkbox' of class 'checkbox'.

The methods would let you define the size of the select list, the available selections, the css class used etc.. i guess.

but how would you design the class for each object, how would use these classes and at the end of the day where is the data stored?

I'm so hardened in relational database / linear programing, like you say, changing the way I think is going to be hard.

lets say i have a form and define all the obejects on it, at the end of the day the purpose is for displaying (usualy) as HTML.

I know you can already use "Templates" for this type of thing in perl, CSS gives you methods for configuring the objects and the CGI module the power for gathering this data and using it in PERL.

You'd then process this data and make the relevant saves to the SQL DB.

How would doing this via OO benefit.

How would you print your form object to the screen for example.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[SPrelewicz]

I was offline for a few days, but I thought Id revive this a little. I very much like the idea of "Collaborating" on a project here to model something. I think, like said above, its be a good idea to try something slightly less concrete than say a Car, to help us along in real world projects.

 

[TrojanWarBlade]

Then what do you suggest?
Since you want something "less concrete", why don't you suggest what you want and we'll try to help you design it.


Trojan.