How does persistence change object architecture?

I'm working with classes in PHP. When I'm writing a class, I'm always thinking "This object is basically a one-off; it's not going to last be开发者_JS百科yond the page load." Consequently, all the logic in my classes basically construct themselves, do a few state changes, give some feedback, and die. Brine shrimp.

Because of this, I've taken to using exceptions to throw almost any and all problems, because I won't be able to have the user interact with the object in case of a problem. Instead, the user gets some feedback on the page about what happened, and then they re-submit the form or whatever. The object is about to die in a few milliseconds anyway, and I won't be able get more input to handle the error.

It seems to me that if I were programming in an environment with persistent objects, I would probably make more robust warning and error reporting and handling in objects, before I had their method terminate with an exception. If an object was still hanging around with an error or warning state, I could get some more input from the user and proceed. So my objects would look and behave differently.

Please note that what I'm asking is not "How do objects behave differently in PHP from other languages?" but rather "When writing object in PHP (or other non-persistent environments), how do those objects differ from when they are able to persist?"

---

I suspect one key aspect would relate to the management of resources, with file handles and memory being obvious suspects. (In terms of PHP, I guess you'd unset large arrays and objects that are in-scope yet no longer required.)

That said, I think a good programmer would code in this manner anyway - leaving file handles open, etc. is fairly shoddy practice even if you know the runtime will take care of such things for you.