A quick OO primer...

You're still violating data-hiding. It took me over a year (and two separate projects) to realize that the method you're using (which I used extensively) isn't OO programming. All you are doing is associating functions with a hash, then unnecessarily abstracting a function call over every access to that hash.

A quick primer on OO ... the idea is that you have these things and each thing can accomplish a certain set of tasks. These task are very abstract, like walk(), dispense_money(), and the like. Then, there is what asks that thing to do whatever. The asker doesn't know nor does he care to know how the thing gets its stuff done. All that matters is results. (In that sense, OO programming could be called "results-driven programming" ...)

A human example would be a manager and an employee. Imperative programming would be like having a manager stand over your shoulder and say "Now, press 'N'. Now press 'o'. Now press 'o'. Now press '!'. ...". This is opposed to Object-Oriented programming where the manager says "Get this task done. You have a week. Tell me when you're done." The second manager doesn't know and doesn't care how you get the job done. He just wants to know that the job is done and done well.

What does this have to do with your case? Well, I haven't read the code. Frankly, it sounds like you're doing imperative programming in OO-clothing. It feels clunky, doesn't it? Sorta like you're trying to get a square peg in a round hole. Well, rethink what you're doing. Identify the things in your design (you do have a design, right?) and identify what each thing can do. Then, let them go and do their jobs without your meddling interference! :-)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on A quick OO primer...

Replies are listed 'Best First'.
Re: A quick OO primer... by synapse0 (Pilgrim) on Sep 11, 2001 at 03:08 UTC
Thanks for the reply.. I'm trying to sort out how directly your statements describe my code. I think I have a competent idea of OO, but since i've never had anyone poke around my code and point things out, I dunno for sure. All you are doing is associating functions with a hash, then unnecessarily abstracting a function call over every access to that hash Well, in this particular case, that's precisely what this object is supposed to do. Really, it's just a config file regurgitator. Is there another way you handle something like this, where the object is there mostly to access specific data, and not make any changes to that data? I hope your go/othello project is going well.. -Syn0	[reply]
Re: Re: A quick OO primer... by dragonchild (Archbishop) on Sep 11, 2001 at 17:21 UTC
Frankly, I'd just use a hash. grins Call a spade a spade. Since you're writing the code, you know exactly how that hash is going to be used. If someone is stupid and violates the contract of that hash ("Don't assign to me cause I'm your configuration values!"), then any problems are their own fault. Objects are supposed to be things that do stuff, not things that act as repositories. (Of course, there're exceptions to every rule, but it's a good starting point.) Now, there is a way to make a good configuration object. You just have to change the way you think about it. What you could do is pass the configuration object a filename. You, as the main program, wouldn't know how the configuration file is set up or what all the things it specifies are. Then, what your main program would do is ask the object if XXX is set to nnn, maybe by doing something like `if ($config->isSet('XXX', nnn)) { # Do something here } else { # Do something else here }` [download] All the parsing of the config file, maybe even writing of a new config file, and everything that has to do with configuration would be encapsulated within this object. The trick is to get the interface right. Your main program doesn't want to know the exact values ... it just wants to know if it can do something based on an attribute's value. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply] [d/l]


Clear questions and runnable code get the best and fastest answer
	PerlMonks