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

 

[TrojanWarBlade]

I'm a bit of an old crinkly and so I might not be the best to advise you.
I'm from the era of top-down programming and therefore I still like to look at things in that way, even object oriented design.
The way I usually approach complex designs is to simplify things by imagining that they're already written and complete.
For example, imagine that all the objects you could wish for and their interfaces are complete.
Now write the top level code that calls them and uses them.
When you write this top level code you'll find it causes you to design the objects and interfaces without having to really think about it too much.
Then, when the top level is complete, look at the next level (the top levels of the objects) and write those. And objects that they might need, treat in a similar way as though they exist already and repeat.
Eventually you'll find you have code that does what you want.
As I said, I'm a dinosaur so I suggest you take my comments with a pinch of salt (as they say).



Trojan.

 

[SPrelewicz]

Yeah, I like your advice. I think my problem is I just cant wrap my head around that high of a level of abstraction, and I just constantly second guess every design decision I make.

But I like the process you explained. Perhaps I should move this thread to the OOP forum for a discussion on how people take the step from specification/analysis to design and some tips.

http://www.flyingroman.com/_about_me

About me at Flying Roman.com lyric meaning and discussion

http://www.scottprelewicz.comScott

Prelewic, Renassance Man

 

[TrojanWarBlade]

I'm amazed I haven't been torn to pieces for my suggestions.
They work for me but I know many will suggest there are far better and more formal ways of doing it.


Trojan.

 

[MikeLacey]

Your methods are more than slightly similar to mine trojan

My first question is always - How do I want to use this object?

I write some sample code, a fair bit of code perhaps, and as I write it I go back over what I've written and refine the way my new object will be called. When I find I've stopped refining - and what I really want is to see the object running - I know that it's time to move on to looking at the guts of the object.

Mike

You cannot really appreciate Dilbert unless you've read it in the
original Klingon.

Want great answers to your Tek-Tips questions? Have a look at faq219-2884

 

[1DMF]

Hey guys i guess I'm an old crinkly as well, I just bite the bullet and run, I know what I want to achieve, I know the data required to be stored and manipulated and then just get on with the code, adding any additional data fields and structure as I need them.

what I want to know is what the hell does object orientated actually mean.

what is the object, and what are we orientating about it ?

Sometimes I find it's the terminology that throws me , not the task in hand.

what is a class and how would you make one and use it ?

I see things like this when developing:

I have a user,
I have data,
They need functionality,

So find out what functionality they need, then simlpy write the code to display and manipulate that data and then store it. - or is that too simple?

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

 

[TrojanWarBlade]

In simple terms, an object is a black box that gives you functionality and manages it's own state internally. You don't have to worry about how it works, you simply need to call it's interface to get what you want.
It's very similar in some ways to modular programming but the big distinctions appear when you look at how you design an object as opposed to a module.
Objects have features that can make re-using them much easier such as inheritance. This is a feature where your new class of object merely adds a few abilities to the parent object to create a child object. This means that if you have a complex class that almost does what you want but just lacks one or two simple features, you can create it without having to re-write the entire class with all it's previous complex functionality.


Trojan.

 

[1DMF]

and now in english please - lol

so is lets say the wininet.dll is this a class or an object or neither, i understood it to be an API.

is an object then a functionality / method not the physical data ( i see an object as an item) be it name, address, an image etc.. but your saying the object is the SQL DB it sits in, am I getting there, knowing me probably not - lol

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

 

[TrojanWarBlade]

And object is NOT data.
Think of your TV remote control unit.
That is an object.
It has an interface (buttons) and can maintain it's own state (with the help of the TV) such as the current volume level and what channel you are currently watching.
The class could be called (say) "remote" and is merely a description of what a "remote" would do if you had one.
When you create an object, you might create one called "myremote" of type "remote". Indeed, you could create (say) ten of them and call them "remote1", "remote2" ...
Each of these objects is an instance of the class remote and will hold it's own state so "remote1" (and it's associated tv) might be on channel 5 whereas "remote2" might currently be on channel 12.
Does that help at all?


Trojan.

 

[fishiface]

My approach is very similar to Trojan's and I've no better advice. I have, however, just completed a very rushed job and used an object hierarchy to good effect so I'll take a few minutes to describe the process I used in case it's of use.

My users have an application with a well-defined character interface and a shell-out facility. The object of the exercise was to provide a simple form-based application that mirrored the interface to which they were all used - to an extent that the users would not realise that they were in a different program.

I started with the terminal attributes. The host app used it's own database and allows users to remap colours, etc, to taste. I wrote a terminal object with methods for each attribute. The new method read the database into a hash and all the unparameterised attribute methods were provided by a single AUTOLOAD. To improve efficiency (this object is getting hammered) I had AUTOLOAD create a new sub returning the required constant and plug the sub into the symbol table. The next time the method was called, the sub would be called directly. I'm not convinced that perl hasn't even in-lined them for me!

I had to do a little work for paramterised attributes, such as cursor motion, but the syntax was identical to that of terminfo, so I could reuse code.

Now I could start on the form itself. A form is a great candidate for an object. Mine has two collections; static, decor objects and active, field objects. It has methods to add objects to it's decor collection or to it's fields collection. It also has a paint() method which simply calls paint() methods for each member of each collection and a run() method which tracks the currently active field. The rorm's run() method calls a run() method for the first field and interprets its return value as a directive to run the next field, the previous field or to exit the form. It sits in a loop doing this until it gets an exit directive (This is the longest sub so far and has about 6 lines).

Decor objects turn out to be easy. Each has a new method which collects parameters and a paint method which draws it. I threw together one- or two-liners for text, boxes, panes (boxes with a highlighted title) and window titles (incorporating the current date and some application-dependent information). The application structure was such that each object and each method "wrote itself" to a large extent.

Fields are more interesting and text fields, date fields, money fields, etc need different handling. I decided to have a single field object to handle construction and painting. All my field objects inherit their new() method and paint() method from a single field object. The new() method simply gathers named parameters into a hash reference and blesses it into the appropriate class. The paint() method relies on all the inheriting objects having the same parameter names for their coordinates, their value and any "standout" modes. I also gave it a method to accept keyboard input and tokenise escape sequences.

Now all I needed to do is write the run methods for my different types of fields. These are nothing more than loops containing big switches to call the inherited get_token() method and compare the returned keycode to all the valid possibilities. Most modify the field's value and repaint but some (such as BACK_TAB) cause field exits, returning an appropriate directive to the invoking form's run() method.

As soon as I'd written the first of these, a Text field, I could run the whole thing. Once the typos were ironed out, it behaved pretty well on it's first outing. I realised that I'd not provided a way for the form object to return the field data but that proved easy to fix: simply provide the Field object with a value() method - it would be inherited by all the field subclasses - and let the form call it on each object in it's field collection.

The above represented about a day's work. I've since bolted on Yes/No/Quit-style confirmation, context-sensitive help, fields that validate their input against a database and some more eye-candy.

Confession: this was the first time that I've used inheritance in production code and I've been absolutely delighted by the way it has worked out. The code looks great: small self-contained subs whose purpose is obvious from the context and whose internals are all properly compartmentalised from each other.

I've been playing with objects for a long time but they've been slow to creep into the day job. This experience has vividly illustrated the power of the metaphor to me and I'm certainly going to be looking for more opportunities to use it.

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]

objects, methods, classes, decor, symbol tables, parameters, attributes, shell out, interface, application, metaphors, switches......

Sorry to much, I didn't understand a word..... think i'll change my job and start emptying dustbins.

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

 

[1DMF]

Trojan, i'm confused to my mind you've contradicted yourself

Think of your TV remote control unit.
That is an object.

then you say

The class could be called (say) "remote"

now is the remote an object or a class ??



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

 

[1DMF]

hang on so $myvar is of class 'scalar' @myarray is of class 'array' - is that it ?

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

 

[fishiface]

They're more types than classes. A class is like a type but with methods.

f

["]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]

so whats a method ? this is way too complicated.

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

 

[TrojanWarBlade]

A class is the definition of the object.
The object it the actual tangible thing.
It's like the plans for a house.
The Class is the plan.
The whole row of houses are Objects (of class HOUSE).


Trojan.

 

[1DMF]

but not all houses are the same, a mansion, a terrace , a castle, are not all the same class.

even a class of house would vary dependant on how many rooms it had.

but trying too look pass this as being possibly a bad example.

the plan tells me how many rooms it has, how many levels, what size they are.

so you have a class which is all the possible attributes of the object. you then define the object by setting each attribute in the class to create the object.

is that right ?



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

 

[TrojanWarBlade]

This is where objects are so good.
All houses have common features.
So maybe you create a room class and a house class.
The house class can have an array of rooms.
If a house needs unusual features like a moat for a castle, you can inherit from the house and create a castle by just adding the moat. The array of rooms still work the same.



Trojan.

 

[1DMF]

How would you add a class to an existing class.... but hey i think i'm grasping the fundamantals slowly.

i take it you don't touch the code already written for a class, how do you bolt your own class to an existing class to save rewriting something already done by someone else?

and then that brings us to what it the method?

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

 

[TrojanWarBlade]

You INHERIT from it.
In perl you add the name of the parent class to an array called "@ISA". Then when perl cannot find a method (function in non object speak) in your class, it looks through the array and checks the classes there for the functionality. If it finds it, it calls it.
Yes?


Trojan.