> > > This isn't quite informative. But objects also make it easier >> to inter-relate a bunch of methods that you haven't necessarily >> programmed yet without having to remember what arguments you >> have to pass around from method to method, because you can get >> them out of $self when you need them in whatever routine. That, >> I would say, is the biggest benefit (to me) for being strict >> about using object structure whenever it makes sense. >> > > Mark >
Agreed, this is a definite benefit during development. But the objects give you an additional, foundational, benefit...it's easier to understand what it is your doing. By separating your domain 'artifacts' into logical objects, similar to how they would exist in real life, it is easier to understand a complex model because it's easier can comprehend the individual abstract parts. Further, adding logical behaviours to these instantiated objects (both static and instance) you can expect a set of behaviours from that object (it's interface), depending on what it is and where in the inheritance taxonomy it falls. This, of course, is very important when you start inter-relating (coupling) objects into coherent components...and even more so when you come back in 6 months and have to add in a similar but ever-so-slightly-different object =). OOP, especially the perl way, give you lots of flexibility...but as you suggested, we have to make the decision when OOP is the right thing to after analyzing all aspects of the project. I agree that the catalouge, in our limited understanding of the requirements, should be a class (perhaps an object, depending on if there is an fact a current or future business need to have multiple catalogues...sometimes, you're only going to represent a single library). Also about the importance of understanding the way mod_perl handles persistance...which can bite you when your not paying attention. S
