OO Design

[Srinivasa Raghavan]

I'm very new to this design stuff. My problem goes like this
I have a Business object ( a Java class ), A class for frontEnd.
I feel this frontend should not directly interact with the business object
( like the methods in the BO should not be visible to the front end )
it should interact to the BO via an interface or a classes , so any change in the bo will not affect the front end.Can any one guide or tell me a correct design for this.

[Stan James]

That's a pretty good thing to be concerned about. Ultimately every component has to have some public API that clients know about so they can call it, so you can't hide everything. But you can do some neat things to make that API more stable or more friendly.

One common technique is the "Facade Pattern". In buildings a facade is a false front that hides ugly stuff like the heat exchanger on the roof, and so it is in objects. I might have a component with a dozen complex objects inside, but a single simple facade for other people to call. The facade is the public API that clients see, and it passes requests on to the more complex objects to do the hard work of the system. The facade can be simple and stable, so if I refactor my dozen complex objects into two dozen simpler ones, callers never need to know the difference.

Does that sound like the right kind of solution? Google for "java facade pattern" for more details.

[Srinivasa Raghavan]

Thanks James , I'll check it out.

[Scott Ambler]

You might find Class Type Architecture to be interesting.

- Scott

[Scott Ambler]

Doh! Hit add reply too soon. :-(

This essay overviews the concept of layering your application and restricting access between layers. It might provide an explanation of the overall concept that you're addressing. I'm actually hoping to update this essay within the next week or two to coincide with some similar writings by Mark Collins-Cope, so expect a few changes.

- Scott

[miguel lisboa]

let me see if i got this correctly:

inside my GUI, there's an ActionPerformed code, where i'v to grab and pass several strings colected from jText fields; then i'v to send them as parameters to some object's method.

well, there are several objects in play: my GUI, my other Obj(s)

the solution would then wrap all this variety of objects inside a new class - the Fa�ade - and then all would be cleaner, because this Fa�ade would have an API (getStrings(), passStrings(getStrings()), etc) that should easily be used by clients

is that it?

is that it?

[Steven Bell]

One implementation of that I've seen work pretty well looks something like this:

1) There is a GUI front end that can usually be broken down into a number of 'screens'. (What you define as a screen is up to you).
2) For each 'screen' you have a 'screenWrapper' class which actually doesn't so much wrap the screen, but provides the facade for that screen to access the business objects.
3) The 'screen' drops it's input into the 'screenWrapper'. The wrapper is able to validate the input (if it wasn't already validated) and put it into the correct place in your business model. If the data validates the wrapper can persist the data.
4) After the 'screen' has dumped it's data into the 'screenWrapper' the screen can check the wrapper for errors before continuing on. This check is ususally done after all the values for that screen are set in case some input relies on other input.

So the flow from the GUI perspective is something like:
An action is taken by the user:
1) Grab the data.
2) Pass the data to the wrapper.
3) Check for errors on the wrapper.
4) Either coninue or alert the user to the errors.

[miguel lisboa]

looks really great

thanks a lot

[Srinivasa Raghavan]

Thanks Scott.