Article: Pipeline to Visitor Design Pattern

Discussions

News: Article: Pipeline to Visitor Design Pattern

  1. Article: Pipeline to Visitor Design Pattern (16 messages)

    In this article, Waleed Hassan presents a new design pattern, Pipeline to Visitor, that handles the issue of building SW components in a way that makes the SW maintainable.
    Moving from Analysis to the Design phase, designers try to make the SW system very maintainable through selecting all the functions that are used frequently by most of the use cases and
    make components out of them. These SW components are usually designed in a form of utility classes that are to be called through the system. These utility classes fit well for the sake of the current system. However, the problem arises when an update in the system should be conducted, like adding an extra parameter for example to some function in the utility class to enhance
    some behavior in that function; then all the callers to that utility class should be made, which actually doesn't make it a component at all.

    Another problem arises when some node in the flow implementing some use case changes in a way that is instead of collecting some data from a DB, for example, it has to be collected from XML, or even from a call to some web service, which is typical to service oriented architecture.

    In addition, a problem would happen if some flow of the application should be exposed later in a form of a web service to be used by an external system.

    The objective is to present a new design pattern - namely, Pipeline to Visitor. This pattern is supposed to handle the issue of building SW components in a way that makes the SW very maintainable. The pipeline to visitor design pattern is best suited in the business logic tier.
    Read Pipeline to Visitor Design Pattern. What are your thoughts on this design?

    And while you're at it, you might be interested in this following warning about the Problems with Design Patterns: Evil Design Patterns Edited by: Cameron McKenzie on Jul 13, 2010 7:17 PM

    Threaded Messages (16)

  2. This looks vaguely familiar, and not in a good way. I generally don't like to see 'a hub and spokes' in a class diagram. I think we really need to see some (preferably simple) code. I didn't see any. Did I miss something?
  3. What the ....!?[ Go to top ]

    Seriously, it looks like reinventing the wheel but make it look like a square. As I understand it, the objective is to eliminate a strong linked relation between actual logic and the facade (pipeline). Which a think is simply crap since aggregating the input now has to be done by the business logic (atleast at the business logic layer), because this logic is responsible for interpreting the Collection (this could simply be Object which makes it sound like a php solution) containing the input. And because we gave ourselves a hard time of making the input generic we give ourselves an even harder time of discovering what it is that actually has been computed (visitor). So you end up with alot of overhead code (creating and reading collections, visit objects) just because you don't want to refactor at a later stage.
  4. It is a good idea to use collections so that the functional unit can support future changes. I don't think this idea is new though. Other than this, I really don't see too much to make it a 'pattern'... Also, the use of pipeline in the business tire would certainly involve something like transaction handling. Any consideration upon that?
  5. you dont avoid code maintenance[ Go to top ]

    by making code unmaintainable. Well defined interfaces trumps this stuff anyday even on a large scale. At least you know what to change when you need to. As far as the visitor pattern itself (with or without pipeline) goes, it seems to be something people just wont let die.
  6. Need code to understand[ Go to top ]

    I know that people love UML to "explain" things, but frankly I don't see what is going on (and the UML image is too small to read too). Maybe some code would be useful. Otherwise, from the description, it looks like reflection is used to build a hashmap which is passed to a visitor so that the hashmap plays the role of a context object and can collect information from some traversal. If that's true then here's my thoughts: 1) Context objects are good. 2) HashMaps for context objects may be a necessary evil, but generally you no longer have type safety. Particularly with reflection being used, a good DI framework like Spring and using real type-safe POJOs is a better way to go. Can you post some code please? Michael
  7. Hi, I have seen this "pattern" implemented in some systems, for the same reasons as stated in the article, and I must say that those have been the most difficult parts of the system to maintain...by far... The use of collections or maps as stated, have actually simplified the initial development but once the projects are over one month old you end up in situations where you have duplicated names, difficult to know the types of the objects you are receiving, etc. Simply put it is a design witch promises much grief in the future and I recommend all to avoid it. It is far better, in my experience, to use overloading or parameter classes in these situations. Then you are at least aided by the compilation to find errors and code completion to write the code…. Just my humble opinion… Daniel
  8. I have to agree...[ Go to top ]

    Seems to me what your modeling is the use cases not the domain.... -Todd
  9. Scary Stuff[ Go to top ]

    I really wasn't able to make heads or tails of the design. But I'm not anxious to work on anything architected this way. When ideas like this are taken too far, pretty soon you have no way to understand how things work except in a running system. Unless you can trace the execution in a debugger you are helpless. I once did work on a system where even the database columns had had nice generic non-descriptive names. The system sure was flexible, but I never did understand how anything worked.
  10. Another problem arises when some node in the flow implementing some use case changes in a way that is instead of collecting some data from a DB, for example, it has to be collected from XML, or even from a call to some web service, which is typical to service oriented architecture. It's called using and interface, for stuff which could change and using something like spring to wire the implementations together cleanly, or if you hate IOC use a Service locator or something In addition, a problem would happen if some flow of the application should be exposed later in a form of a web service to be used by an external system. Knowing exactly what service your that your gui is actually calling via and interface makes maintenance a lot easier than having to map functions and parameters. furthermore your interfaces in your service tier are your end points, and if they are designed properly you should have no problems exposing them as services, plus you get transactions for free
  11. Bad idea[ Go to top ]

    "It's called using an interface, for stuff which could change and using something like spring to wire the implementations together cleanly, or if you hate IOC use a Service locator or something." ADMIN DECISION: CORRECT ANSWER This pattern looks nice in UML and appeals to an ordered mind but it is not a good approach. Also, I would love to see performance statistics on an application built with this pattern. With similar hardware, there are much better patterns already implemented by frameworks like Spring, Seam or Ruby on Rails. The last two are lean and mean and would blow this app out of the water. AR!! This guy has a government job waiting for him. He needs to bow out of the private sector.
  12. I help design a small BPM engine that worked in a very similar way. The process itself was composed of a hierarchy of objects that themselves contained very little except parameter information and visitor redirection. The processor then just visited the hierarchy doing what ever it was supposed to do. Some points: 1. The visitor pattern works very well when the visitees are a graph which has to be flexible and subject to change, or where new components must be added. 2. Visitors are not just business processing executors. They may transfer to/from DB, validate, XMLify, etc. The same graph is used for each. 3. I don't think generic collections are a good idea. There are other mechanisms that can be used to look up the visitor component to run that don't add much to the maintenance overhead. Overall, I believe this is roughly the right approach, but I'm not sure it is really a pattern. It is an implementation of the good ol' Visitor pattern. MHO Kit
  13. Collections for Context is evil[ Go to top ]

    Using Collections as a dumping ground for context is very very bad for maintenance. The longer the project goes and grows, the harder it is to figure out what objects in the collections are meant for each component without a very thorough documentation. I've maintaned a system that does this once, and it was a nightmare. External developers that tried to integrate into the system also experienced the same problem. We have a HashMap that hold context information for the whole system. Unfortunately, througout the years, this has been abused to the state where the single HashMap now contains graphs of objects with nested graphs HashMaps. Just trying to extract the proper context object out of it takes a herculean effort. I'd prefer to have different interfaces to pass context info between components and business layers. That way, there is no confusion on whether I am using the right context or not. I dont waste time trying to extract the proper context.
  14. Using Collections as a dumping ground for context is very very bad for maintenance. The longer the project goes and grows, the harder it is to figure out what objects in the collections are meant for each component without a very thorough documentation
    I agree with yuor post here and it seems to me that this is yet another way to try to circumvent static typing in Java. If you really want to get rid of static typing, just use another language that is dynamically-typed like Python.
  15. First, this seems to be an architectural pattern which is making use of a number of design patterns, rather than a design pattern. As has been mentioned previously my biggest concern is the use of a collection instead of an object. Generics in Java 5 has given us an opportunity to use stronger typing, so we can catch more bugs at compile time. This pattern is reversing the trend by causing the bugs to happen at runtime instead. If I have understood this pattern correctly it uses a visitor pattern to handle the code changes. I have major concerns about how many unit tests would be required to test all the variations on this to ensure the correct methods are called. I would suggest that the author look at Drools. (I am still working with the Codehaus version rather than JBoss Rules.) You put all your objects into its Working Memory (a collection of objects) and it finds which classes to invoke depending on the types of the objects and any other conditions you care to define. IMHO it is a nicer way to match objects to parameters than a Hashmap.
  16. Coding for change is an anti-pattern[ Go to top ]

    Since when was code supposed to be written to avoid the necessity of future code changes? This has been the source of SO much abuse and misuse of java and the source of anti-patterns since day one. Given the bugs and unreliability of software with or without change this isnt much of a requirement. Stop writing bad code and using the possibility of future change as an excuse. Write good code and change it well. Thats what we all get paid to do. Dont say you cant use a straightforward implementation because something might change. Hogwash!
  17. Since when was code supposed to be written to avoid the necessity of future code changes?

    This has been the source of SO much abuse and misuse of java and the source of anti-patterns since day one. Given the bugs and unreliability of software with or without change this isnt much of a requirement.

    Stop writing bad code and using the possibility of future change as an excuse.
    Write good code and change it well.
    Thats what we all get paid to do.

    Dont say you cant use a straightforward implementation because something might change. Hogwash!
    aka YAGNI :)