VerificationViaAOP
From APIDesign
(New page: Modular applications assign its every piece certain role. One module shall provide API for access to storage, one for displaying wizards, etc. Other module...) |
|||
| (One intermediate revision not shown.) | |||
| Line 1: | Line 1: | ||
| - | [[Use Modular Architecture|Modular applications]] assign its every piece certain role. One module shall provide [[API]] for access to storage, one for displaying wizards, etc. Other modules depend on such [[API]] modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified. | + | [[Use Modular Architecture|Modular applications]] assign its every piece certain role. One module shall provide [[API]] for access to ''storage'', one for displaying wizards, etc. Other modules depend on such [[API]] modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified. |
| - | Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work | + | Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to [[Java_Monitor|synchronization and deadlocks]] to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work for everyone running on background. When you are supervising such modular system finding and preventing such ''inverted'' dependencies that violate overall assumptions is one of the biggest priorities. |
| - | :There are various extensions to [[NetBeans]] [[Virtual File System]] library | + | :There are various extensions to [[NetBeans]] [[Virtual File System]] library, |
| - | : | + | :including support for [[CVS]], [[Subversion]] or [[Mercurial]]. To deal with VCS |
| - | :is slightly harder then traditional task of regular file system. | + | :is slightly harder then traditional task of regular file system. Sometimes |
| - | :they need to make decisions and they | + | :they need to make decisions and they need to ask user questions. Indeed this |
| - | :was very deadlock prone and needed to prevented and [[TryCatchRedo|fixed]]. | + | :was very deadlock prone and needed to be prevented and [[TryCatchRedo|fixed]]. |
Simplest fix, especially if you own both [[API]]s is to set some '''ThreadLocal''' variable whenever a method from storage [[API]] is on the stack and whenever one tries to show a wizard or dialog verify that this '''ThreadLocal''' is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern. | Simplest fix, especially if you own both [[API]]s is to set some '''ThreadLocal''' variable whenever a method from storage [[API]] is on the stack and whenever one tries to show a wizard or dialog verify that this '''ThreadLocal''' is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern. | ||
| - | As such I was very pleased to see [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini Penchikala's presentation] describing use of [[AOP]] for the same task. Instead polluting | + | As such I was very pleased to see [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini Penchikala's presentation] describing use of [[AOP]] for the same task. Instead polluting both the [[API]]s with '''ThreadLocal''' tricks and making them semi-aware of each other (wizard do not need storage otherwise), one can define one or two ''aspects'' externally and achieve the same. |
| - | For preventing these kinds of unwanted compile or runtime dependencies the [[AOP]] seems to be perfect. Get more | + | For preventing these kinds of unwanted compile or runtime dependencies the [[AOP]] seems to be perfect. Get more inspiration by [http://www.slideshare.net/srinip/architecture-enforcement-aspects-itarc2009-1117942 Srini]. |
<comments/> | <comments/> | ||
[[Category:Tools]] | [[Category:Tools]] | ||
Current revision
Modular applications assign its every piece certain role. One module shall provide API for access to storage, one for displaying wizards, etc. Other modules depend on such API modules and use them get the data from the storage or display their wizard dialogs. The intuition clearly indicates that by wrapping all the complexity of dealing with storage into a separate module, the overall complexity of the code is simplified.
Still, it is important to put and enforce certain restrictions on the interactions between various modules. For example it can be extremely dangerous with respect to synchronization and deadlocks to allow those who implement storage to try to display dialogs or wizards. The access to screen may already be occupied by someone else, yet the storage access needs to work for everyone running on background. When you are supervising such modular system finding and preventing such inverted dependencies that violate overall assumptions is one of the biggest priorities.
- There are various extensions to NetBeans Virtual File System library,
- including support for CVS, Subversion or Mercurial. To deal with VCS
- is slightly harder then traditional task of regular file system. Sometimes
- they need to make decisions and they need to ask user questions. Indeed this
- was very deadlock prone and needed to be prevented and fixed.
Simplest fix, especially if you own both APIs is to set some ThreadLocal variable whenever a method from storage API is on the stack and whenever one tries to show a wizard or dialog verify that this ThreadLocal is not set. If it is, rise an exception. This is simple, yet it feels like quite a brute force hack than a recommended pattern.
As such I was very pleased to see Srini Penchikala's presentation describing use of AOP for the same task. Instead polluting both the APIs with ThreadLocal tricks and making them semi-aware of each other (wizard do not need storage otherwise), one can define one or two aspects externally and achieve the same.
For preventing these kinds of unwanted compile or runtime dependencies the AOP seems to be perfect. Get more inspiration by Srini.
<comments/>
Follow
