reviewed, small additions
This commit is contained in:
parent
5ea8943a01
commit
e08fc6cdc8
2 changed files with 51 additions and 35 deletions
|
|
@ -1032,7 +1032,7 @@ cinelerra3/mob is an anonymous account at pipapo.org where everyone can commit c
|
|||
* on the question who decides what to do after a cache miss, we tend to put the decision into the render node (because this seems to be the simpler aproach), but still have to work out the details.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="IRC_2008-02-01" modifier="Ichthyostega" modified="200802030342" created="200802021821" tags="irclog" changecount="20">
|
||||
<div title="IRC_2008-02-01" modifier="Ichthyostega" modified="200802031846" created="200802021821" tags="irclog" changecount="28">
|
||||
<pre>! 1. feb.2008 on #openvideo
|
||||
21:00 -23:30 GMT. __Participants__:
|
||||
* hermanr
|
||||
|
|
@ -1047,17 +1047,18 @@ cinelerra3/mob is an anonymous account at pipapo.org where everyone can commit c
|
|||
* Velmont
|
||||
|
||||
!! Discuss the open points in http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess &mdash; do we need this formalism?
|
||||
At start of the project last summer, Cehteh made a [[design process proposal|http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess]]. We will keeping this up, not for every implementation detail, but for mayor plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue
|
||||
At start of the project last summer, Cehteh made a [[design process proposal|http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess]]. We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue
|
||||
* proposals in the "idea" state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page.
|
||||
* proposals in the "draft" state are ready for conclusive discussion and will be treated in one of the next meetings
|
||||
* "final" proposals are either "accepted" or "dropped". We don't differentiate the latter, but should write a short note why it was dropped.
|
||||
* if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views
|
||||
|
||||
!! The development model
|
||||
We employ a distributed model based on GIT. We want this repository to be as complete as possible, including documentation in embedded ~TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a "Mob GIT", i.e. anonymously pushable git (which is untrusted of course). Cehteh is currently working on a git web frontend which makes the codebase in the mob-repo web-editable like a wiki.
|
||||
Will we need a stable version or an official branch? not yet &mdash; as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
|
||||
Ichthyo proposes a new requirement: All devs should ensure the "master" branch of their respective repositories always passes the compiler and the test suite. ~Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator.
|
||||
A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature &mdash; esp. when it fits into the core focus of the project &mdash; instead of depending on difficult to build and not sufficiently maintained external project. But we should avoid reinventing things like GUI toolkits.
|
||||
And, pretty much obvious, we try to stick to modern programming standards. That means, modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion.
|
||||
A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature &mdash; esp. when it fits into the core focus of the project &mdash; instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits.
|
||||
And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion.
|
||||
Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, ~Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the ~Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use.
|
||||
We plan to make the discussion about GPL v3 a point on the agenda of the next meeting.
|
||||
|
||||
|
|
@ -1067,25 +1068,28 @@ We plan to make the discussion about GPL v3 a point on the agenda of the next me
|
|||
* write a short status report for each mayor part //prior// to the meeting (saves us time). Maybe add an TODO list there
|
||||
* go through the open issues for the design process drafts
|
||||
* publish a protocol of each meeting on the (~Cinelerra-CV, ~LibOpenvideo) Mailinglists, in the TiddlyWiki and on pipapo.org
|
||||
* News, Protocols and the agenda of the next meeting can be found at the [[pipawiki-page|http://www.pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings]]
|
||||
* next meeting on first Thursday in March (6.3.2008)
|
||||
|
||||
!! Who works on what, what are the short term goals, what tasks are open?
|
||||
''Ichthyo'' works on the processing layer. Current goal is to get the core of the builder fleshed out. Next goal is to create a clip object (dummy), add it to the EDL, hand the EDL over to the builder and let the builder make the first (preliminary) render nodes. (note: left many details for later).
|
||||
Ichthyo started coding his design draft and things seem to work out as intended. Some Keywords: Have a high-level model and a low level model. The former are the objects in the Session edited by the user, the latter is a network of completely configured render nodes, employing the same pull model as in Cinelerra-2. In between sits the Builder, translating high-level into low-level. This translation is done on demand (not for every frame).
|
||||
Ichthyo started coding his design draft and things seem to work out as intended. Some Keywords: Have a high-level model and a low level model. The former is comprised of the objects in the Session edited by the user, the latter is a network of completely configured render nodes, employing the same pull model as in Cinelerra-2. In between sits the Builder, translating high-level into low-level. This translation is done on demand (not for every frame).
|
||||
Current state in this part is: basic asset manager is done, asset objects (forming a hierarchy) can be created and will be registered automatically, it is possible to create a clip-"~MediaObject" from a media asset (without caring for any details regarding multichannel clips). Some support lib components are written, Session and data holders start up on demand and shutdown cleanly. The test suite is the only interesting executable, and this will remain so for quite some time. Currently writing the first parts of the Builder.
|
||||
Further plans/ideas: Ichthyo is rather determined to embed a Prolog interpreter (YAP Prolog) to handle all sorts of configuration queries in a rule-driven fashion. Things Ichthyo can't do in the near future: caring for session loading/saving serialisation plus storage backends, caring for a DB based implementation of the asset manager and integration with production support software, target the scheduler which will receive any edit operations initiated from the GUI.
|
||||
|
||||
''Cehteh'' is currently working on webgit, which is somewhat related inasmuch it will make small contributions to the mob repository much simpler. Previously he started with some foundation and support facilities. He plans to come back to the Backend implementation in about two weeks. The Backend is intended to handle all media (and even meta-)data as generalized frames. The render nodes network created by the ~Proc-Layer is completely stateless and all data is served from below. While it will be possible to address and access individual data within a frame (e.g. audio samples), frames are the smallest unit for memory and cache management. No plans to use a tiled memory model or to support frames larger than aprox. 20-40% of the available RAM.
|
||||
Cehteh's design plan includes a scheduler to organize the access to the raw data, monitor the timings and prefetch data as needed. This scheduler will be configurable via quality preferences ("need realtime", "need perfect quality"). Further, there will be an elaborate caching scheme trying hard to avoid re-rendering any frames already calculated previously. Temporary data will be backed by files and thus swapped out &mdash; this swapout and size of temporary data is to be monitored and adjusted on load &mdash; and all temporary data is kept as most-recent-used cache discipline. Incoming and outgoing footage shall mostly be handled by using mmaped buffers. The rationale is to avoid unnecessary copy from kernel to user space and wasting memory for an additional in-kernel buffer. Writing via a mmapped buffer is little more tricky; there will be a in-place writing which is used for indices and other precalculated data which needs updates, and the processing layer can query write buffers which are actually a small cache/ring and then comited to the file. Basically, mmapping is a clean solution if you can design for it, and it's portable (posix)
|
||||
Cehteh's design plan includes a scheduler to organize the access to the raw data, monitor the timings and prefetch data as needed. This scheduler will be configurable via quality preferences ("need realtime", "need perfect quality"). Further, there will be an elaborate caching scheme trying hard to avoid re-rendering any frames already calculated previously. Temporary data will be backed by files and thus swapped out &mdash; this swapout and size of temporary data is to be monitored and adjusted according to the current load &mdash; and all temporary data is kept as most-recent-used cache discipline. Incoming and outgoing footage shall mostly be handled by using mmaped buffers. The rationale is to avoid unnecessary copy from kernel to user space and wasting memory for an additional in-kernel buffer. Writing via a mmapped buffer is little more tricky; there will be a in-place writing which is used for indices and other precalculated data which needs updates, and the processing layer can query write buffers which are actually a small cache/ring and then comited to the file. Basically, mmapping is a clean solution if you can design for it, and it's portable (posix)
|
||||
Things to do: object serialisation backend is sometime on Cehteh's schedule, but that's ahead and if someone else helps or takes over it would be OK. Even more true for a DB based backend for the asset manager.
|
||||
|
||||
''Gmerlin'' plans to implement grayscale support for GAVL, so the upper layers can store arbitrary data in it.
|
||||
|
||||
__about multithreading__: since the render nodes are stateless they can be driven in multiple threads (but inter frame dependencies need to be resolved/serialized). Mostly the backend manages threads and does that quite conservatively (compared to Cinelerra-2 which massively creates separate threads for small tasks). Any edit operations initiated from GUI go to a scheduler in the middle layer, which enqueues and effectively serializes operations done to the "media objects" in the high-level model. The editing operations themselves are //not threadsafe // by design, they rely on being scheduled correctly. The builder is triggered from this ~Proc-Layer scheduler and starts in one separate thread, and when done, we swap whole parts of the render nodes network and then the backend can re(start) rendering as needed.
|
||||
|
||||
!!The naming discussion
|
||||
The discussion looks healthy so far... People can add new proposals on the [[pipawiki|http://www.pipapo.org/pipawiki/Cinelerra3/Names]]. intersting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we //can// depart from beeing similar to "Cinelerra" ;-)
|
||||
Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being:
|
||||
* should not be an existing project
|
||||
* should be "googeable"
|
||||
* should be "googleable"
|
||||
* should not be offensive
|
||||
* should have one of the free top level domains (.net, .org)
|
||||
* should be compatible with educational institutions (sorry, no pr0nedit :)
|
||||
|
|
|
|||
|
|
@ -833,8 +833,8 @@ This is an very important external Interface, because it links together all thre
|
|||
* completely hide the Session object behind a ''~PImpl'' smart pointer, so the session object can be switched when reloading.
|
||||
* the [[Fixture]] acts as isolation layer, and all objects refered from the Fixture are refcounting smart pointers. So, even when the session gets switched, the old objects remain valid as long as needed.</pre>
|
||||
</div>
|
||||
<div title="DefaultTiddlers" modifier="Ichthyostega" modified="200706190047" created="200706172308" changecount="2">
|
||||
<pre>RenderEngine
|
||||
<div title="DefaultTiddlers" modifier="Ichthyostega" modified="200802031805" created="200706172308" changecount="6">
|
||||
<pre>[[ProcLayer and Engine]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="DefaultsManagement" modifier="Ichthyostega" modified="200801171440" created="200801121708" tags="def spec" changecount="5">
|
||||
|
|
@ -957,7 +957,7 @@ To make the intended use of the classes more clear, consider the following two e
|
|||
<pre>A special kind (subclass) of [[Placement]]. As such it is always linked to a //Subject//, i.e. a MObject. In addition to the properties of a (unspecific) Placement, the ExplicitPlacement specifies a absolute time and track position for locating the Subject
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Factories" modifier="Ichthyostega" modified="200708112256" created="200708100401" tags="impl discuss" changecount="18">
|
||||
<div title="Factories" modifier="Ichthyostega" modified="200802031822" created="200708100401" tags="impl discuss excludeMissing" changecount="19">
|
||||
<pre>We use Factories
|
||||
* for centralizing [[memory management|MemoryManagement]]
|
||||
* to support polymorphism (of course...)
|
||||
|
|
@ -1109,7 +1109,7 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
|
|||
&rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200801171322" created="200708080322" tags="overview" changecount="20">
|
||||
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200802031829" created="200708080322" tags="overview" changecount="21">
|
||||
<pre>This wiki page is the entry point to detail notes covering some technical decisions, details and problems encountered in the course of the implementation of the Cinelerra Renderengine, the Builder and the related parts.
|
||||
|
||||
* [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
|
||||
|
|
@ -1123,7 +1123,7 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
|
|||
* [[using the Visitor pattern?|VisitorUse]] &mdash; resulting in [[»Visiting-Tool« library implementation|VisitingToolImpl]]
|
||||
* [[Handling of Tracks and Ports in the EDL|TrackPortEDL]]. [[Handling of Tracks|TrackHandling]] and [[Ports|PortHandling]]
|
||||
* [[getting default configured|DefaultsManagement]] Objects relying on [[rule-based Configuration Queries|ConfigRules]]
|
||||
* [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreaterTool]]
|
||||
* [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreatorTool]]
|
||||
* [[how to handle »attached placement«|AttachedPlacementProblem]]
|
||||
</pre>
|
||||
</div>
|
||||
|
|
@ -1524,9 +1524,9 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
|
|||
[img[Classess related to the EDL|uml/fig128133.png]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="MainMenu" modifier="Ichthyostega" modified="200708080314" created="200706172305" changecount="9">
|
||||
<div title="MainMenu" modifier="Ichthyostega" modified="200802031758" created="200706172305" changecount="10">
|
||||
<pre>''[[Cinelerra3|index.html]]''
|
||||
[[RenderEngine]]
|
||||
[[Proc-Layer|ProcLayer and Engine]]
|
||||
[[MObjects]]
|
||||
[[Implementation|ImplementationDetails]]
|
||||
[[Admin]]
|
||||
|
|
@ -2298,7 +2298,7 @@ afterwards.
|
|||
<<tasksum end>>
|
||||
</pre>
|
||||
</div>
|
||||
<div title="PlanningNodeCreaterTool" modifier="Ichthyostega" modified="200801111250" created="200712090659" tags="impl Builder draft" changecount="8">
|
||||
<div title="PlanningNodeCreatorTool" modifier="Ichthyostega" modified="200802031829" created="200712090659" tags="impl Builder draft" changecount="1">
|
||||
<pre>//This page is a scrapbook for working out the implementation of the builder//
|
||||
|
||||
* NodeCreaterTool is a [[visiting tool|VisitorUse]]
|
||||
|
|
@ -2412,10 +2412,34 @@ We need to work out guidelines for dealing with operations going on simultaneous
|
|||
* all EditingOperations are not threadsafe intentionally, because they are [[scheduled|ProcLayerScheduler]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Proc-Layer and RenderEngine" modifier="Ichthyostega" modified="200802030402" created="200706190056" tags="overview" changecount="1">
|
||||
<div title="Proc-Layer" modifier="Ichthyostega" created="200802031814" tags="def" changecount="1">
|
||||
<pre>The current Cinelerra-3 architecture separates functionality into three Layers: __GUI__, __Proc__ and __Backend__.
|
||||
|
||||
While the Backend is responsible for Data access and management and for carrying out the computation intensive media opteratons, the middle Layer or ~Proc-Layer contains [[assets|Asset]] and [[Session]], i.e. the user-visible data model and provides configuration and behaviour for these entities. Besides, he is responsible for [[building and configuring|Builder]] the [[render engine|RenderEngine]] based on the current Session state.</pre>
|
||||
</div>
|
||||
<div title="ProcAsset" modifier="Ichthyostega" created="200709221343" tags="def classes" changecount="1">
|
||||
<pre>All Assets of kind asset::Proc represent //processing algorithms// in the bookkeeping view. They enable loading, browsing and maybe even parametrizing all the Effects, Plugins and Codecs available for use within the Cinelerra Session.
|
||||
|
||||
Besides, they provide an important __inward interface__ for the [[ProcNode]]s, which will use these asset entries to dispatch the actual processing call when rendering.
|
||||
|
||||
{{red{todo: the naming scheme??}}}
|
||||
|
||||
[img[Asset Classess|uml/fig131077.png]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ProcLayer" modifier="Ichthyostega" modified="200708100338" created="200708100333" tags="def" changecount="2">
|
||||
<pre>The middle Layer of our current Architecture plan, i.e. the layer managing all processing and manipulation, while the actual data handling is done in the backend and the user interaction belongs to the GUI Layer.
|
||||
|
||||
&rarr; see the [[Overview]]
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ProcLayer and Engine" modifier="Ichthyostega" modified="200802031830" created="200706190056" tags="overview" changecount="4">
|
||||
<pre>The Render Engine is the part of the application doing the actual video calculations. Its operations are guided by the Objects and Parameters edited by the user in [[the EDL|EDL]] and it retrieves the raw audio and video data from the [[Data backend|backend.html]]. Because the inner workings of the Render Engine are closely related to the structures used in the EDL, this design covers [[the aspect of objects placed into the EDL|MObjects]] as well.
|
||||
<<<
|
||||
''Status'': started out as design draft in summer '07, Ichthyo is now in the middle of a //first, draft, prototypical// implementation in C++
|
||||
''Status'': started out as design draft in summer '07, Ichthyo is now in the middle of a implementing the foundations and main structures in C++
|
||||
* basic AssetManager working
|
||||
* currently impmenenting the Builder (&rarr;[[more|PlanningNodeCreatorTool]])
|
||||
<<<
|
||||
|
||||
!Summary
|
||||
|
|
@ -2434,23 +2458,6 @@ The system is ''open'' inasmuch every part mirrors the structure of correspondin
|
|||
&rarr; how [[Automation]] works {{red{to be defined in more detail}}}
|
||||
&rarr; [[Problems|ProblemsTodo]] to be solved and notable [[design decisions|DesignDecisions]]
|
||||
&rarr; [[Implementation Details|ImplementationDetails]] {{red{WIP}}}
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ProcAsset" modifier="Ichthyostega" created="200709221343" tags="def classes" changecount="1">
|
||||
<pre>All Assets of kind asset::Proc represent //processing algorithms// in the bookkeeping view. They enable loading, browsing and maybe even parametrizing all the Effects, Plugins and Codecs available for use within the Cinelerra Session.
|
||||
|
||||
Besides, they provide an important __inward interface__ for the [[ProcNode]]s, which will use these asset entries to dispatch the actual processing call when rendering.
|
||||
|
||||
{{red{todo: the naming scheme??}}}
|
||||
|
||||
[img[Asset Classess|uml/fig131077.png]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ProcLayer" modifier="Ichthyostega" modified="200708100338" created="200708100333" tags="def" changecount="2">
|
||||
<pre>The middle Layer of our current Architecture plan, i.e. the layer managing all processing and manipulation, while the actual data handling is done in the backend and the user interaction belongs to the GUI Layer.
|
||||
|
||||
&rarr; see the [[Overview]]
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ProcNode" modifier="MichaelPloujnikov" modified="200706271500" created="200706220409" tags="def" changecount="3">
|
||||
|
|
@ -2726,6 +2733,11 @@ The link between ~MObject and Asset should be {{{const}}}, so the clip can't cha
|
|||
At first sight the link between asset and clip-MO is a simple logical relation between entities, but it is not strictly 1:1 because typical media are [[multichannel|MultichannelMedia]]. Even if the media is compound, there is //only one asset::Clip//, because in the logical view we have only one "clip-thing". On the other hand, in the Session/EDL, we have a compound clip ~MObject comprised of several elementary clip objects, each of which will refer to its own sub-media (channel) within the compound media (and don't forget, this structure can be tree-like)
|
||||
{{red{open question:}}} do the clip-MO's of the individual channels refer directly to asset::Media? does this mean the relation is different from the top level, where we have a relation to a asset::Clip??</pre>
|
||||
</div>
|
||||
<div title="RenderEngine" modifier="Ichthyostega" modified="200802031835" created="200802031820" tags="def" changecount="2">
|
||||
<pre>Conceptually, the Render Engine is the core of the application. But &mdash; surprisingly &mdash; we don't even have a distinct »~RenderEngine« component in our design. Rather, the engine is formed by the cooperation of several components spread over two layers (Backend and Proc-Layer): The [[Builder]] creates a network of [[render nodes|ProcNode]], which is used by the Backend to pull individual Frames.
|
||||
&rarr; OverviewRenderEngine
|
||||
</pre>
|
||||
</div>
|
||||
<div title="RenderEntities" modifier="Ichthyostega" modified="200706220406" created="200706190715" changecount="6">
|
||||
<pre>The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of [[Processing Nodes|ProcNode]] discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
|
||||
|
||||
|
|
@ -4091,7 +4103,7 @@ Using transitions is a very basic task and thus needs viable support by the GUI.
|
|||
Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their "simple" counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output ports as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a inconsistently placed transition is just an [[building error|BuildingError]])
|
||||
</pre>
|
||||
</div>
|
||||
<div title="VisitingToolImpl" modifier="Ichthyostega" modified="200801051747" created="200801032003" tags="impl" changecount="20">
|
||||
<div title="VisitingToolImpl" modifier="Ichthyostega" modified="200802031822" created="200801032003" tags="impl excludeMissing" changecount="21">
|
||||
<pre>The ''Visitor Pattern'' is a special form of //double dispatch// &mdash; selecting the function actually to be executed at runtime based both on the concrete type of some tool object //and // the target this tool is applied to. The rationale is to separate some specific implementation details from the basic infrastructure and the global interfaces, which can be limited to describe the fundamental properties and operations, while all details relevant only for some specific sub-problem can be kept together encapsulated in a tool implementation class. Typically, there is some iteration mechanism, allowing to apply these tools to all objects in a given container, a collection or object graph, without knowing the exact type of the target and tool objects. See the [[Visitor Pattern design discussion|VisitorUse]]
|
||||
|
||||
!Problems with Visitor
|
||||
|
|
|
|||
Loading…
Reference in a new issue