General J2EE: More philsophy: Should patterns drive the design process?

  1. I posted a note a week or two ago about my confusion over "classic" object-oriented design and what I see in the architecture design patterns literature.

    My thoughts are becoming clearer, and my initial thought is that the design process is becoming patterns-focused rather than being driven by OO design principles. What do I mean by that? Patterns are fairly post-hoc. They describe how OO systems end up, but I'd argue should not drive the process. Don't get me wrong, I think patterns are a great communication tool and accurately describe common design characteristics, but I just don't think it's appropriate to drive the design process with them

    Let me give an example. I do a lot of Java training. In one of my early classes on OO and Java I have students model the game rock-scissors-paper. Basically, I ask them to consider a rock-scissors-paper player and ask them to model the class with me. What are a player's properties and operators? This example is nice because there are only one or two properties and operators. After this is designed I ask them to implement it in Java and write a tester routine. For the tester I ask the students to create two RspPlayer objects, then in a loop have the players take a turn, compare their hands to see who one, and display the result.

    (I'm leading up to my point!) After they get everything working I display a typical tester routine and comment that it has a lot of business logic embedded in it. I then ask the class what the tester is really doing. After a pause several people will say, "It's playing the game!" Ah ha! We've identified a new class, Game, which encapsulates that concept. We then model the properties and operators of Game and implement it. Our tester now simply creates the players, the game, and in a much simpler loop -- void of business logic -- runs "play()" on the Game and displays the result. I'd say this is classic OO design that is application-driven. I.e., we are modeling the problem domain through analysis and discovery.

    (Here it is!) If I were following the philosophy of the modern architecture design community I would teach this very differently. After modeling and implementing RspPlayer and the first tester routine I'd say, "Client code, such as your tester should never interact with business classes directly. The right technique is to code a 'Facade' class and call it from the client." We could call the facade something like "RspPlayerFacade" and add methods that match our use cases. Etc. The resulting code is very similar to that in Game; but on a conceptual level, modeling and implementing a Game class is a lot clearer and intuitive than starting out thinking you're modeling a Facade.

    OO design is good because your designs model easy to identify and easy to understand classes in the problem domain. Literacy in patterns is great -- it lets you look out for common situations and describe some design features, but I'm arguing that it should not drive the process.

  2. Interesting but I must say while reading through your post it appears that your are contradicting yourself.

    You mention how that when you approach the problem using conceptual designs you identify that you need a facade. And further on that the fascade class mimiced what the game class was doing. Isn't that what design patterns are suppose to do, model a concept in software design.

    Though I do not know the level of expertise of your class. From your post it appears that the question you posed to them was in the context of a group that is not yet exposed to patterns yet. You as the teacher knew exactly what it was, and thus opened the eyes of your students to the role it plays. You are pointing out a pattern you have defined in your own mind, but you see it as indirectly related to a model that has been given a name...fascade. Correct me if I'm wrong.

    It's the "Oh I knew that, now I have a name for it." case. Everyone experiences it. But in the context of an inexperienced group presenting something in the form of an abstract pattern modeled after a real software deisgn issue isn't really going to help them too much. They, like everyone else at one point in time, need to be exposed to various situations in which these patterns arise.
  3. I guess I'm arguing that when modeling a domain one shouldn't think "I probably need a facade." Classes should simply reflect concepts from the domain. Does rock-scissors-paper "need" a facade? I don't see how one can think in those terms during domain analysis. However, the concept of a "game" is obvious. Although upon reflection you may discover that some classes act as facades, and use that term to describe it to other developers.
  4. Hi,

    IMHO I think you are thinking about your facade incorrectly. Personal I would create a GameFacade which supports the use cases the Game supports. In this case the "player" concept becomes the client of the GameFacade. IMHO Facades offer services and in this model the Game is the service not the player.

    Players have no business logic in them and generally just support the concept of the user of the game.

    One interesting question in this design is where you store the state of the game. If you are against statefull session beans you should implement your facade as a stateless bean and pass the state in when you pass the player.

    As for the domain model and pattern usage. Domain models for me general just map the concepts of the domain we are modelling. They are quite removed from technology and patterns. Patterns come a lot more into play when we try and build the Implementation Class Model.

    Anyway, just my initial thoughts,
  5. PS.

    Of course your game could be more persistent in how it stores the state for the player. In this case the games state for that player would go in the DB.

  6. Is this really about the actual design and architecture of this game? I thought it was mearly an entry point to a greater discussion.
  7. I thought the example he used to push his point forward of how the use of the facade pattern made him change his design had a flaw in it (IMHO).

    My point (and I sorry if I waffled on a bit too much) was that the Game concept could still exist even if we used the facade pattern and therefore the use of the pattern had changed nothing.
  8. Yes, the Game example was just used as an entry point to a general discussion. About Game versus Facade -- my point is that Game *is* a Facade in this example, but that concept of a Game emerges naturally from the analysis process. Driving the analysis process looking for Facades leads to the creation of classes that don't match the domain and are perhaps too arbitrary.

    By the way, thanks for the thought-out comments.
  9. Hi,

    I agree that domain models should not be pattern driven. For a domain model you should be keeping things as strictly OO as possible.

    For me patterns come in when I start building the implementation class diagram. This is when I map the domain to the technology I am going to use to build the system.

    Sorry if my earlier thoughts were a little of base. Its been a long week. Reading you post again I could I done a better answer.

  10. Max,

    if I get you right, you are argueing that the analysis should drive the design, just to get rid of patterns applied to the wrong places. I agree to that. Often we can find too many levels of indirection and abstraction where multilayered delegation simply slows applications down. The trick is, as always, to use patterns with care. You should not try to overengineer your application, leading to a result which is from a software engineers point of view a state-of-the-art solution, but lacks performance and will therefore never be scaled up to the levels it was build (and engineered) for in the first place.

    On the other hand, the development process you describe is an emergent one, which means it is very difficult to plan it. If I have to insert facades while already implementing, this will lead to serious problems in larger projects, as you can imagine.

    And I want to question the need for a game object as well, if the only thing the "client" application will be doing is game.play() ... :)

    Just my $.02,
  11. Everyones' comments have helped clarify my thinking. Thanks.

    My clearer(?) perspective is that J2EE Patterns are just that -- patterns relating to designing applications *using J2EE*. J2EE apps all probably do need a facade. Coincidentally, Game filled that role too. And if I were implementing rock-scissors-paper as a J2EE app, it might make sense to simply use Game as the facade to the server app. So facades *may* be relevant to some arbitrary app like rock-scissors-paper, but coding a facade session bean for a J2EE app is almost certainly needed.

    Re: Domain patterns driving design

    I was once on an interesting project in the utilities industry group of a large consulting firm. The project's mission was finding reuse oppurtunities among projects -- i.e., domain reuse. We found that there is quite a lot of reuse potential within that domain. In other words, one project's data flow diagrams, data models, methodology best practices, etc., were very likely to be of use on another utilities project. So, I would say "yes, domain patterns probably should drive the design process."
  12. I think it is very important to notice the difference between Patterns and OO (OOA/OOD/OOP). The lay definition of a Pattern could be: "A pattern is a tested and repeatable way of designing a solution to a given problem or sets of problems." For instance, two design groups can come up with different approaches to a solution to a similar problem. Patterns help architects compare how others who have faced a similar problem, have gone about designing a solution to the problem (i.e., why re-invent the wheel?). There is a lot of talk about facades, singletons, etc, etc without consideration of their advantages and disadvantages, if any. The reasons for employing the so called design patterns is to help develop solutions that are scalable, maintainable, implementable, cheap, etc. Not all problems require the utilization of patterns.
  13. The fundamental point here is that there is more to OO modelling than design. Domain models, specification models, system design and technical architecture are all valid applications of OO modelling - each with a specific objectives. Patterns - documented ways of solving common problems - may be found in all of these areas.

    For example, common domain patterns include 'scheduling' and 'billing'. Process patterns include 'iterative development' and 'waterfall'. Not all of these relate to the concrete classes and objects of an OO system.

    The contention in this discussion thread is that the development of these models are essentially separate activities, and that patterns applying to one type of model are not necessarily applicable to another.

    Patterns posted in TheServerSide tend to focus on architectural design - a fact which reflects the interests of the group. Max is correct to point out that these architectural design patterns do not normally drive the development process.

    Question: How about domain patterns? Should they be allowed to 'drive' the development process?