little_mistress has asked for the wisdom of the Perl Monks concerning the following question:
My problem is this, finding the resources that explain the concepts of organizing objects, rather than simply telling me what an object is.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: How to think.
by chromatic (Archbishop) on Apr 01, 2000 at 03:31 UTC | |
The best advice I can give you is to do a lot of thinking, a bit of research on how objects are handled in other languages, and a lot of diagramming how real world things are put together. For example, suppose you are designing a race track. You know you will need a track, cars, and spectators. What are the similarities of all of those things that you can generalize into a parent object? What are the differences (that matter to your application) that you want to list specifically in each object? Are there any special types of any object that would best be served by subclassing it?
| [reply] |
Re: How to think.
by stephen (Priest) on Apr 01, 2000 at 04:27 UTC | |
Design Patterns by Erich Gamma et al is an excellent book that distills the experience of a whole bunch of developers and analysts. The whole field of patterns is more or less what you're describing. Analysis Patterns by Martin Fowler does something similar, but it's mostly for really, really big systems, like accounting and healthcare systems. Hmm... and Code Complete by Steve McConnell(?) offers some good stuff, too, although he talks about *modules* as opposed to *objects*. The only other rule that I know is... practice being wrong frequently. As I'm quite sure you know, there's no trick to understanding large projects, just experience and finding out what works for you. People break down projects into smaller bits because projects get too large to keep in your head all at once. So, experiment with different breakdowns for a system, since there's no one right answer. Think on paper. If you're visual, draw diagrams. If you're language-oriented, scribble notes. Some people keep Legos on their desks to build little models. Once you've got it out of your head, show it around to other people, who can sometimes see flaws. ("Um, why're you subclassing by gender? They've got the same methods, how about making it an attribute?") System design is not a science, and there are no hard-and-fast procedures. Since I'm a linguistic thinker, I generally start by scribbling down a description of the problem, then start scribbling a list of classes that I think would help to solve it. Once I get bored with that, I take the objects I've got and scribble some notes indicating how they'll all interact to solve the problem that the system's supposed to solve, and add and subtract objects as needed. Then I take another look at my list of objects and see if some need to be broken down further. Then I take a few of the most central, important-seeming objects, and take a crack at developing 'em. Generally, this suggests some more classes, so I jot them down. Sometime around here I start bugging my coworkers/friends about whether my design looks vaguely good, or if I'm off the deep end again, and they'll say nice things like, "Stephen, it only needs to accept credit cards. You didn't need to write a whole new language." Sorry to ramble... too much tea... | [reply] |
Re: How to think.
by mothra (Hermit) on Apr 06, 2001 at 17:37 UTC | |
That said, I like to either draw diagrams or write things down, or both. Programming is much more reality-based than a lot of people realize (because ultimately anything you code turns into either 0's and 1's or "bytecode" which is, like, weird). One question that I'm always asking when thinking about designing an object is: From that the methods and attributes become clear. For example, in the app I'm working on, I created a "table service" object (Powerbuilder calls them objects, but you might refer to them as classes as well). What does the table service know? It knows: As it turns out, I did write a table service, but it wasn't quite as ambitious as the list above (ie. I hardcoded the INSERT's in my code, it's not yet a capability of the table service). And this list simplifies it somewhat, because the table service is really a wrapper around an array of table objects, each of which has its own array of column objects. But hopefully you get the idea. In fact I use this question all the time. I use it for debugging apps, configuring apps, understanding my environment and more. For example, I had a problem with a web site host (for a site I'm developing for a client) where I would go to www.thedomainiregistered.com and it wouldn't go to the /home/username/public_html/ dir that it should have (instead, it went to a system-wide DocumentRoot, because obviously the admin hadn't yet put my homedir's public_html dir as the DocumentRoot). I thought to myself "Apache should know that when I say www.thedomainiregistered.com it should go to my /home/username/public_html/ directory". In other words, the concept of "who knows what" made me realize that it wasn't a programming problem, but an incompetent Apache admin. As it turns out, I'm in the process of dealing with this being fixed right now. :) | [reply] |
Re: How to think.
by Jammer (Novice) on Mar 28, 2002 at 16:01 UTC | |
Ask yourself "who or what does *things* within this system?", then ask "what is it that they do?". Also, on a personal note; I tended to find when I started using OO as a methodology, I worried a little too much about when and where to use inheritance. My tip is; you don't need to use inheritance as much as you might think, the component-based approach can often be better (i.e. the "HAS-a-whatever" rather than "IS-a-whatever". To take an example (from, I think, some of the perl OO docs); you might think that you should have a virtual base class Employee, which you would subclass to, say, DeveloperEmployee and ManagerEmployee and ProjectManagerEmployee because all three are (for sure) employees of one kind or another. But consider for a moment the notion that an Employee (as a concrete class, i.e. one having instances) could have an *attribute* of role, which would the be DeveloperRole or ManagerRole or ProjectManagerRole; you than have the flexibility of variable behaviour from one Employee to another, without the rigidity enforced by an inheritance hierarchy. Employees can change roles without losing their identity, which more closely models the real(tm) world. On a more general note, I would say; ease into it gently. One of the *many* joys of Perl (and for me, the principal one), is that there's no "proper", enforced way to do things. Enjoy the freedom from having to do OO all-at-once as you'd have to do with (say) Java, and just dip a toe. You don't have to intimidate yourself with doing the whole OO-design thing right from the off, you can just experiment and become comfortable with one concept at a time. OO *CAN* be fun, if you take it one step at a time. Forgive the rambling post, I'm having an evangelical moment. | [reply] |
Re: How to think.
by SoftTerrier (Initiate) on Dec 05, 2002 at 18:33 UTC | |
| [reply] |
Re: How to think.
by Doraemon (Beadle) on May 13, 2004 at 08:56 UTC | |
I learn OO mostly through C++ book (i meant the good one). Usually the examples are solid enough (or maybe because C++ is the best candidate for OOP? you decide!) | [reply] |