Re: Deletion practices

Responding to Nathan...

Interesting what you say about the factory handling deletion, I'd
never heard of that.

Yeah, I've never understood why it doesn't get more press. It seems pretty obvious, given OO encapsulation, though. The rules and policies of instantiation (Who) are usually different than those of collaboration (What & When), so it makes sense to encapsulate them away from individual collaborations via "factory" objects and patterns.

But the rules and policies of de-instantiation are pretty much a mirror image of those for instantiation. In addition, one is dealing with exactly the same concerns: referential integrity (relationships) and data integrity (initialization and availability). One uses objects to encapsulate logically related concerns. So where else would one put that logic?


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Manager object or Static or Instance Funtion
    ... uncomplicated one it can be sufficient to encapsulate it in a single ... context> responsibilities)... ... policies have been honored. ... and policies for initial instantiation are significantly different than ...
    (comp.object)
  • Re: Manager object or Static or Instance Funtion
    ... > uncomplicated one it can be sufficient to encapsulate it in a single ... > context> responsibilities)... ... > policies have been honored. ... > and policies for initial instantiation are significantly different than ...
    (comp.object)