(chromatic) RE: High-level methods to low-level: Do I put them together?

I've done a bit of thinking on that very issue for Jellybean, as a matter of fact. Our design will probably end up using interface-type code and helper objects.

Take the DBI and DBD architecture, for example. If you want to store your data in a database, write to the DBI interface, and let people use whichever DBD matches their database of preference. I say, write your high-level objects generically enough that they can use any helper objects with the right interface. (I guess that means, make polymorphic helper objects.)

That means that you can just flip the switch of changing which specific helper object to use, rather than recoding bits and pieces of your main object. If you're good, you can even pass a reference to your preferred helper to the main object constructor.

Comment on (chromatic) RE: High-level methods to low-level: Do I put them together?

Replies are listed 'Best First'.
RE: (chromatic) RE: High-level methods to low-level: Do I put them together? by jeorgen (Pilgrim) on Jul 17, 2000 at 03:03 UTC
Thanks, chromatic for your reply. I have gone through your answer a couple of times and had the opportunity to discuss with my colleague Uno, who is a Java programmer ( us two together is pretty much a company meeting :-). I'm starting to grok what he's saying now. The DBI/DBD example you gave is also elucidating. I am a systems analyst by training, but just before they started teaching object oriented analysis and design, so I missed out on that part. One thing I did learn was though that it's good if an application you make can cope with change. So now over to the question at hand: High-level methods to low-level: Do I put them together? It seems OK to mix levels of methods in a class. As long as you don't see any problems with a changing environment, that will force you making you recode a little bit here and a little bit there. It is not so smart to mix in lower levels of methods in a class, if you expect them to change depending on the deployment or implementation of the application. In that case it's better to factor them out so you can do the change in one place. You could even change what classes are used at run time by making a factory. More about factories further down. If somebody else has made a good class (e.g. at CPAN) that does a lot of the stuff you could probably cajole it into working in your application by putting some kind of wrapper code around it to make it fit with your application. In object parlance I've lerned now this is called to make an adapter. Uno managed to dig up a URL to some web pages that describes the patterns in the "Gamma" book, which seems to be a kind of bible about patterns in OOD. One pattern is called factory, and it seems to be constructor that can decide what kind of object to construct at run-time. I think this is similar to what you call the main object constructor. I suppose that instead of a parameter it could check a configuration file (or object) in order to decide what kind of object to return, e.g. "MySQL is true". It could also just try (e.g. with eval) to create objects of different classes according to an ordered list. I suppose this is the way the AnyDBM module at CPAN works. The adapter pattern is a way to connect an object to another object, where certain method and attribute names are expected in the communication. The adapter object then goes in between to translate. So it's an interface translator, though perl doesn't have explicit interfaces as does java. It could be used to cajole in a class from CPAN in a place it didn't expect :-) I didn't find any info on helper objects and polymorphic objects, but I guess that you would create these and store them by reference in a slot in e.g. the Category object? Going back to the practical case of my log analyser, it seems unnecessary to factor out the match_line or store_event methods etcetera, that would just create a lot of small classes. There is a data structure called "Tree" that could be made into some kind of general tree-storage class, but will probably not be worth the effort. /jeorgen	[reply]

Replies are listed 'Best First'.

RE: (chromatic) RE: High-level methods to low-level: Do I put them together?
by jeorgen (Pilgrim) on Jul 17, 2000 at 03:03 UTC

I am a systems analyst by training, but just before they started teaching object oriented analysis and design, so I missed out on that part. One thing I did learn was though that it's good if an application you make can cope with change.

So now over to the question at hand: High-level methods to low-level: Do I put them together?

It seems OK to mix levels of methods in a class. As long as you don't see any problems with a changing environment, that will force you making you recode a little bit here and a little bit there.
It is not so smart to mix in lower levels of methods in a class, if you expect them to change depending on the deployment or implementation of the application. In that case it's better to factor them out so you can do the change in one place. You could even change what classes are used at run time by making a factory. More about factories further down.
If somebody else has made a good class (e.g. at CPAN) that does a lot of the stuff you could probably cajole it into working in your application by putting some kind of wrapper code around it to make it fit with your application. In object parlance I've lerned now this is called to make an adapter.

Uno managed to dig up a URL to some web pages that describes the patterns in the "Gamma" book, which seems to be a kind of bible about patterns in OOD.

One pattern is called factory, and it seems to be constructor that can decide what kind of object to construct at run-time. I think this is similar to what you call the main object constructor. I suppose that instead of a parameter it could check a configuration file (or object) in order to decide what kind of object to return, e.g. "MySQL is true". It could also just try (e.g. with eval) to create objects of different classes according to an ordered list. I suppose this is the way the AnyDBM module at CPAN works.

The adapter pattern is a way to connect an object to another object, where certain method and attribute names are expected in the communication. The adapter object then goes in between to translate. So it's an interface translator, though perl doesn't have explicit interfaces as does java. It could be used to cajole in a class from CPAN in a place it didn't expect :-)

I didn't find any info on helper objects and polymorphic objects, but I guess that you would create these and store them by reference in a slot in e.g. the Category object?

Going back to the practical case of my log analyser, it seems unnecessary to factor out the match_line or store_event methods etcetera, that would just create a lot of small classes. There is a data structure called "Tree" that could be made into some kind of general tree-storage class, but will probably not be worth the effort.

/jeorgen

[reply]