Storing intermediate objects (for "visual debugging")
in [OOP]
|
From: Thomas Kowalski on 8 Aug 2007 09:27 Hi everyone, currently I am working on some graphical software. Since it's not really possible to write classical unit-tests for this kind of problems the application is solving, I need to verify the results by seeing them. Which means that the intermediate data (let's call them resources) the software produces shall be visualized in the OpenGL- View. This way I can check that correct behavior of the application in a blink of an eye. Since at later time many more types of resources may be added I decided to implement some kind of "repository" there collections of resources are stored. I can disable the visibility of each object and/ or collection for the "visual check". A repository is NOT a singleton since every document I open (MDI-Application) has it's own one. The problem now is that a reference to the right repository is needed nearly every there in the code which I think is a pretty ugly code- smell. Besides the benefits in debugging the repository also facilitates the lazy instantiation of different resources, which hopefully improves the execution speed of the application. Before I had created the resource at the point they were needed and also stored them in these objects. That resulted in a complex hierarchy. It was difficult to control the visibility of the given properties. Does anyone have suggestions how to improve the design of the application? Is the repository (or the other classes depending on it ) a code-smell? If yes, what might be a work around? Regards, Thomas Kowalski
From: H. S. Lahman on 8 Aug 2007 14:28 Responding to Kowalski... > currently I am working on some graphical software. Since it's not > really possible to write classical unit-tests for this kind of > problems the application is solving, I need to verify the results by > seeing them. Which means that the intermediate data (let's call them > resources) the software produces shall be visualized in the OpenGL- > View. This way I can check that correct behavior of the application in > a blink of an eye. > > Since at later time many more types of resources may be added I > decided to implement some kind of "repository" there collections of > resources are stored. I can disable the visibility of each object and/ > or collection for the "visual check". A repository is NOT a singleton > since every document I open (MDI-Application) has it's own one. > > The problem now is that a reference to the right repository is needed > nearly every there in the code which I think is a pretty ugly code- > smell. Besides the benefits in debugging the repository also > facilitates the lazy instantiation of different resources, which > hopefully improves the execution speed of the application. I'm not sure I see the problem. What you describe so far sounds like: [DebugDisplayer] | 1 | | R1 | | displays info from | * [Repository] + isVisible | 1 | | R2 | | contains | * [Resource] + isVisible So the only one that needs a Repository reference is the object that is managing the debug display of the intermediate results. I can envision situations where the Repository to be used in a particular debug display depends upon a specific dynamic context. In that case, though, a 1:1 relationship parallel to R1 could be instantiated by whoever understands that context. Then DebugDisplayer would simply navigate to whichever Repository was on the other end. Alternatively I could envision something like: [DebugDisplayer] A | R1 +---------+--------+---... | | [ContextA] [ContextB] | 1 | 1 | | | R2 | R3 | | +-- [Repository] --+ uses 1 | 1 1 uses | | R4 | | contains | * [Resource] In either case I don't see the reference to a particular Repository being strewn around the application with abandon. The relationship either exists in the problem space or it doesn't while separation of concerns and encapsulation drive on only a limited number of objects collaborating. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Thomas Kowalski on 9 Aug 2007 01:28 > I'm not sure I see the problem. What you describe so far sounds like: > > [DebugDisplayer] > | 1 > | > | R1 > | > | displays info from > | * > [Repository] > + isVisible > | 1 > | > | R2 > | > | contains > | * > [Resource] > + isVisible > What you call the "DebugDisplayer" is simply the View (like in the MVC- Pattern) and it has a one-to-one relationship with the repository. > So the only one that needs a Repository reference is the object that is > managing the debug display of the intermediate results. The problem is rather that the "factory-classes" generating the intermediate data need some reference to the repository to store the just generated data. Because of a rather complex hierarchy this is a bit annoying. The other thing I might of course do is returning the result to the top-level element (which in this case would be the only one having an reference to the repository), which of course also would have to travel up through this hierarchy and therefore might be considered equally nasty. > I can envision situations where the Repository to be used in a > particular debug display depends upon a specific dynamic context. > In that case, though, a 1:1 relationship parallel to R1 could be > instantiated by whoever understands that context. Then DebugDisplayer > would simply navigate to whichever Repository was on the other end. I don't get this one. Could you elaborate a little bit more on this? Thanks a lot for your help, Thomas Kowalski
From: H. S. Lahman on 9 Aug 2007 11:15 Responding to Kowalski... >>So the only one that needs a Repository reference is the object that is >>managing the debug display of the intermediate results. > > > The problem is rather that the "factory-classes" generating the > intermediate data need some reference to the repository to store the > just generated data. Because of a rather complex hierarchy this is a > bit annoying. The other thing I might of course do is returning the > result to the top-level element (which in this case would be the only > one having an reference to the repository), which of course also would > have to travel up through this hierarchy and therefore might be > considered equally nasty. Ok, but I still don't see the problem. B-( Presumably a single "factory" is invoked to create a Repository and another "factory" is invoked to create a Resource in each problem context. The "factory" creating the Resource would be responsible for adding it to the right Repository collection for the context. So there would still only be one "factory" object needing a reference to a particular Repository. I assume the hierarchy you are referring to provides different flavors of "factory" objects for different solution contexts (i.e., to produce the right Resource data for later dumping). So one would have something like: [ResourceFactory] A | R1 +---------------+----- ... | | [TypeA] [TypeB] | 1 | 1 | invokes | invokes | | | R2 | R3 | | | 1 | 1 [ContextX] [ContextY] // various solution contexts // producing intermediate data There would be a parallel set of relationships between specific "factory" types and specific Resource types to be created: [ResourceFactory] A | R1 +-------------------+----- ... | | [TypeA] [TypeB] | 1 | 1 | | | R2 | R3 | | | creates | creates | 1 | 1 [ResourceX] [ResourceY] | * | * | contains | contains | | | R4 | R5 | | +-- [Repository] ---+ 1 | 1 1 | accesses | | R6 | | 1 [View] It would up to the "factory" type to know which Repository the created Resource is associated with and instantiate the R4/R5 relationship. So except for the Repository container there should be very few Resource or Repository references floating around since all the relationships have 1 multiplicity. (Obviously View needs a reference to Repository to dump the data, but you indicate that is 1:1.) If this speculation is not correct then I am missing something about the requirements and you need to be more specific about the problem being solved. >>I can envision situations where the Repository to be used in a >>particular debug display depends upon a specific dynamic context. >>In that case, though, a 1:1 relationship parallel to R1 could be >>instantiated by whoever understands that context. Then DebugDisplayer >>would simply navigate to whichever Repository was on the other end. > > > I don't get this one. Could you elaborate a little bit more on this? It is not relevant if the relationship between View and Repository is inherently 1:1. It is just the notion of a "current" relationship. I assumed there may be many Repositories that save different categories of intermediate values but only one may be relevant for a particular debugging context at a time. If the debug facility is complex enough, then navigating from View to Repository might need to be done many times in a given debug context, in which case one does not want to muck around with searching the relationship set for each access. So one does the search once and instantiates a "current repository" relationship as soon as the particular debug context prevails. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Thomas Kowalski on 10 Aug 2007 04:40 Before I start commenting on each paragraph, I just want to say that your assumptions are 95% correct. The main repository contains a collection for each type of intermediate data. Each context X that produces a resource Xn need a reference to that special collection to add the data. So lets assume we have a hierarchy of different producing contexts ( each have at least one factory method for some resource ). contextA ( produce Resource R1) | |--- contextB | | | |--- contextB1 ( produce Resource R2 ) | | | |--- contextB2 ( produce Resource R3 ) | |--- contextC (produce Resource R4 ) We have a Repository containing four collections ( one for each type (R1-R4) ). That would mean that I need to provide the references for the given collections to the given context: contextB1 ---- Collection<R2> contextB2 ---- Collection<R3> contextB ---- Collection<R2>, Collection<R3> contextC ---- Collection<R4> contextA ---- Collection<R1>, Collection<R2>, Collection<R3>, Collection<R4> So instead of providing a reference to each collection for contextA it would make sense to provide the reference to the repository directly. Same goes for contextB, especially since there might be other contexts added lower in the hierarchy and/or more resources needed to be stored. For the other contexts I guess it would make sense to just provide a reference to the right collection. Back to my original question. Is the passing around of references a necessary evil or is there any nice pattern that might simplify my design a bit? Somehow it feels strange that even a context that don't add anything to the repository ( like e.g. B ) needs to hold a reference to the repository since it violates the law of demeter and increase the coupling. > Presumably a single "factory" is invoked to create a Repository and > another "factory" is invoked to create a Resource in each problem > context. Yes, that's correct. To clarify my lingo: The Repository is the factory and the container for each collection of a special type of intermediate data / resource. > The "factory" creating the Resource would be responsible for > adding it to the right Repository collection for the context. So there > would still only be one "factory" object needing a reference to a > particular Repository. Correct. Each context just need a reference to small number of resource-collections. But it need to also provide the references to the sub-contexts (see the beginning of the post). > I assume the hierarchy you are referring to provides different flavors > of "factory" objects for different solution contexts (i.e., to produce > the right Resource data for later dumping). Correct. > There would be a parallel set of relationships between specific > "factory" types and specific Resource types to be created. Correct. > It would up to the "factory" type to know which Repository the created > Resource is associated with and instantiate the R4/R5 relationship. Also correct. The problem is that each super-context (e.g. in the picture B would be the super-context of B1 and B2) need to also know the references of it's sub-contexts, which might be quite a lot because of the complexity of the hierarchy of contexts. > It is not relevant if the relationship between View and Repository is > inherently 1:1. Yes, the relationship between the view and the repository is 1:1. The view just prepares the rendering context and calls the repository which in turn let each collection draw itself, which in turn let every resource draw itself. The container provides the details of how to draw to the resource (drawing mode, color, line thickness, etc.). Thanks again for taking the time to help me, Thomas Kowalski
|
Next
|
Last
Pages: 1 2 Prev: Pattern for user rights on form's objects Next: Leader/Follower design pattern question |