Jerry Jalenak wrote:
I have an order screen where a client can, well, order one or more items. The struts action picks up the item number and hands it off to a business class. The business class goes to the database (DAO), and based on what comes back, either returns a JavaBean containing the item information, or a status indicating out of stock, no longer carried, etc. Since I can only return one object from a method, I either end up adding a 'status' field to the JavaBean, or I end up returning a type of 'Object' and checking in the action to see if it is a type of JavaBean or not - if not, I cast it to an Integer (or String) object, and figure out what happened. If it is a type of JavaBean, then I go merrily on my way. The other option is to code unique exceptions and throw OutOfStockException (for example) and have the action 'catch' it and handle it. Frankly, I don't like any of these options, but can't seem to find any other options.
Well, this is totally a judgement call, and I wouldn't be in a position to give a suggestion either way without being involved in the development and working with the code. I'm sure you'll find a workable solution. My own leaning is toward using the exceptions, though. In an ecommerce site, I'd query the data store (which could be the DB or a cache) to determine what to display, the user would make their selections, and then I'd attempt to populate their shopping cart with the objects. If somehow the objects are no longer available at the time that I try to do this, I can throw an exception, otherwise the shopping cart is populated and I forward to the next page. If an exception -is- thrown, on the other hand, I stop shopping-cart-processing altogether and create a message explaining the problem to the user, and forward to a page that displays the message and gives the user options as to where to go from here.
Side note: I like returning Object from a method -- it's rarely, rarely necessary, and in Java, it's a pain to deal with Object instances (because you can't send an arbitrary message to an object, you have to make an explicit cast to appease the compiler).
I have a 'Constant' class where I put values that are used for storing objects in an HttpSession. Should these be re-coded to use the TypeSafe Enum pattern?
That's entirely up to you -- I'd say, if you don't need type-safe enum and you already have a working model that doesn't use type-safe enum, don't go making more work for yourself. When the time comes that the requirements/demands of your project necessitate that you use the type-safe enum pattern (say, you need to release a developer API with a library of code, and you want to make sure that client programmers use only legal values) then you can always re-code it at that time.
Generally, if I have something that works, I leave it alone until it needs to be fixed or improved, and then when that happens I take it upon myself to refactor the code to make better use of design patterns etc. Of course, when possible I try to incorporate these patterns into the original design of the project so that they are present from step 1.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
