|
Re: Object functionality?
by vladb (Vicar) on May 10, 2002 at 13:39 UTC
|
Every project normally starts out with a thorough study of application specifications and design. Provided design is done properly, you shouldn’t have to deal with such issues as ‘multi-purpose’ modules that are nothing but a ‘package’ crammed with as much functionality as only possible. Modules (in Perl specifically) inherently should serve the purpose of separating one piece of functionality from the rest of your program. Not to mention advantages of software reuse.. but that’s a different subject anyways ;).
I have found a number of posts made by other monks that speak to this affect:
- Thoughts On Object-Oriented Module Design. Input Sought.
- Coming up with code design
There’s also a good book that I might suggest you look into for ideas on proper software design:
Object-Oriented Analysis and Design with Applications, Third Edition
|
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
|
| [reply] |
|
|
Recently while working on Text::Quote and Data::BFDump I came across this debate as well. There are unfortunately more sides to it than you post here.
For instance, I want to have certain functionality that another module has, but I dont want my module unusable if they dont have that module. What to do? Farm it out if the other is there but fallback to a local implementation? Completely use your own and remove the dependency?
Also sometimes you need features of other mdules in your module. Do you then go on to expose those features through your own interface or force the user to use two seperate objects?
I have to say that I have gone both ways, sometimes exposing the functions sometimes not. I think this is one of the areas where the "Art" of rpogramming comes in. Some people seem to know just exactly where to draw the line, others do not. Unfortunately im one of the later.
But having siad that I would say that the rule from cooking probably applies: too much seasoning can spoil the soup.
Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.
| [reply] |
Re: Object functionality?
by Matts (Deacon) on May 10, 2002 at 14:54 UTC
|
Write your tests first. If you do that, it will become obvious how your API should work, and you'll adjust your tests until they look and feel right.
Seriously, it sounds strange, but it really works well. Try it. | [reply] |
|
|
| [reply] |
|
|
Anyone have any links to good tutorials on how one goes about using this approach? I mean it sounds like a fine idea, but (not being a CS type myself) I wouldn't know where to begin....
..Jon
Update: OK, so I guess the answer (thanks to demerphq++) is to look up the Test::More module. THanks!
| [reply] |
|
|
|
|
|
|
|
|
|
|
Writing the tests first is an excellent way to get a handle on how your objects should work, but I think newbie monks especially, and those unfamiliar will benefit from more information about Extreme Programming, as that is the origin of the whole idea of writing your tests first, and Unit Testing.
See Demerphq's post below, as well as the 'official' site for more information.
| [reply] |
|
|
I don't think XP was the point of origin for either writing tests
first or unit testing, as I have worked with teams where both
practices were followed long before XP ever came on the scene. XP
more or less just subsumed and/or modified many practices that its
originators felt were the good ones under the umbrella namespace of
Extreme Programming. Not that that detracts from XP or following the
link you provided for more info.
| [reply] |
|
|
I don't know where you get your information, buzzcutbuddha,
but I was writing tests before functions and unit testing
my pieces long, long before I'd heard of "Extreme" anything.
XP may advocate these practices, but it is not their origin.
| [reply] |
|
|
|
|
Extreme Programming ... they should call you buzzwordbudha ;)
| [reply] |
Re: Object functionality?
by perrin (Chancellor) on May 10, 2002 at 17:07 UTC
|
Remember that OO programming is largely about modeling your data. Start with the data. Draw a diagram in UML or an old-school database ERD so that you can see the distinct pieces and how they fit together. Then add the functionality on top of that.
The best thing to do to improve these skills is to get a job working with some people who are good at OO modeling and pay attention. Failing that, books can help. Get the beginner books; don't try to jump into some crazy design patterns book right off the bat. | [reply] |
|
|
It is also a good idea to keep in mind supportability and reusability when creating objects. Unfortunately, this -- "$x=new obj; $x->start;$x->finish;" -- is not very supportable. Try breaking things up with data in mind, but also breaking up objects in "the obvious way". It doesn't matter what methodology you use, but if you come back to the application 6 months later and have no clue what the objects do, you are stuck "re-creating" the wheel to maintain the code.
As far as reusability, you have no chance in reusing an object (on another application, inside the same application, etc...) if your object is cram packed with functionality. Too many resources.
| [reply] |
Re: Object functionality?
by rinceWind (Monsignor) on May 10, 2002 at 15:16 UTC
|
My feelings on this subject are that you need to consider what type of parameter(s) are going to be passed to a given sub that you are writing.
- Will you be passing in a pre-existing object? If so, this is an object method, and write it as such.
- Will you be passing in a class name instead? If so, make it a class method.
- Otherwise, if it is a straight utility function which does not take either a class or an object as a mandatory parameter, it is a standalone function. Make it optionally exportable.
Sometimes there is synergy between cases 1 and 2 here, and so the construct my $pkg = ref($self) || $self;
does the trick.
Having a heteromorphic sub that does the third case as well is hard to achieve and not worth it. But, this is what CGI.pm does - see this node. | [reply]
[d/l] |
Re: Object functionality?
by abatkin (Sexton) on May 12, 2002 at 07:20 UTC
|
Object Oriented programming is certainly a popular phrase these days, and rightly so. The only problem is that no one ever talks about when it is not appropriate to use OOP. So just think about whether you should use OOP before you figure out how to mold your program to it. Simply because everyone else is doing it, doesn't mean you have to. My theory is that everyone else will tell you how great OOP is (and they are right) but here are some links that you might want to at least take a brief look at:
| [reply] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |