How to think.

[little_mistress]

My problem is this. Although I'm good enough with perl, (ie. if I don't know I pretty much can find the answer on my own.) What I have problems with is planning larger applications. Ideally, I would have to imagine that most larger applications would best be handled by OO Programming, in just about any language. What I need is this, a way to think about planning objects, organizing them, sort of um ... composing and then orchestration.

My problem is this, finding the resources that explain the concepts of organizing objects, rather than simply telling me what an object is.

[chromatic]

Lots of people swear by the book "Design Patterns". I am finding Object Oriented Perl to be a very useful book.

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?

• Track... no big thing here. Seems like a one-shot object.
• Cars... at the very least, things like acceleration, tires, and engines will be different. Maybe they each need to be subclassed, maybe they can just be member attributes.
• Spectators... size of hair, number of velvet Elvis paintings owned, days since last tornado, these can all be member attributes. Perhaps you can define subclasses for gender.
Okay, it's not the greatest example, but if you do that for real-world things a few times, you'll get better at it. It helps to know exactly what kind of data you need now. Then worry about making it more flexible later.

[stephen]

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...

[mothra]

I currently work on a large OO project in my day job (not in Perl though). It's certainly true that there's no magic answer about how to deal with a huge application. You just have to familiarize yourself with it, and realize the importance of experience.

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:

What does this object know?

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:

• How to add a new table (by giving it a name ie. "table_serv.add_table('#TEMP_TABLE')".
• How to add columns to the table (ie. a prototype for that function might be "table_serv.add_column(string name, string coltype, bool allow_null)"
• How to create the table in the database.
• How to drop said table.
• How to make a modification to the table's definition.
• How to insert rows of data into itself.

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. :)

[Jammer]

I know it sounds a tad naive, but the 'nouns and verbs' approach *can* work quite well with OO.
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.

[SoftTerrier]

You might design the industry-strength application? Actually you need modularity and scalability then. The application should remain maintanable and flexible. You do need design patterns! But be aware that Perl design patterns are quite idiomatic:) They differ from C++ design patterns. So use the perlish patterns and build the application. The key word is 'to build' the application instead of to 'to code'. There is an entry point: http://www.slowass.net/wiki2/assemble.cgi?PerlDesignPatterns The good idea is to avoid them all at once. Different layers require different set of patterns. And different application scale also want various approaches. Thats it.

[Doraemon]

When thinking about a large system, think that there should be more than one classes in that system. Every class should communicate/interact (sending/receiving messages) with each other, otherwise don't take that class as part of the system. Think of a car, that has 1 engine and 4 wheels (etc). We can simply takeout one wheel, and change with a new one, without affecting other class (engine etc) or even other wheels (same class but different object). I want to suggest an important thing, make sure AN OBJECT DOES NOT (HEAVILY) DEPENDS ON OTHER OBJECT. That's all that i can think of for now! :) ...
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!)