Facade Or Controller

[Prashant Saraf]

Hi,

I have doubt about naming one the module in webservice. We are using JAXWS webservice, the Service implementation Class called A CLASS. This class basically does role of calling transformer if JAXB object need to translation into other business object, calling services beans and DAO classes and at the send the JAXB response back. There are different opinion are coming in my team about naming the class as either Facade/Controller/Helper/or any other. Can some one help me suggest name according to design pattern concept, I think it should be Facade as it hides the behind implementation from Service as it take JAXB and return JAXB.

[Junilu Lacar]

From what you describe, the confusion and difficulty you are having in coming up with a suitable name may be coming from the fact that this class has too many disparate responsibilities. I can't be sure until I see some code though but that's what it sounds like to me.

When this happens to my team, I just make up a nonsense name and focus on refactoring the class so it is more cohesive and coherent. After a few rounds of refactoring and consolidating the class responsibilities, the appropriate name to give the class becomes more apparent.

[Prashant Saraf]

Thanks Junilu.

The class as a operation that is being called by service impl, this method take jaxb and return jaxb below is some what code looks like. its does not does many things than connecting the dots. the method is not more than 40 line for now.

public JAXB getDetails(JAXB  jaxbRequest)
	{
		JAXB  jaxbResponse; = new CommercialPolicyTO();
		try
		{
			//Convert Jaxb object to Entity 
			EntityFactory agrmntFactory = new EntityFactory ();
			MyEnity enity= agrmntFactory.getMyEnity(jaxbRequest);		
			
			//Call DAO						
			MyDAO dao = new MyDAO ()
			MyResponseResultEnity responseEnity = dao.getMyResponseEnity(enity);
                       
                        //Call more DAO

			// Send Entity to JAxbFactory for Prepare Response
			ResponseFactoruy rspf = new ResponseFactoruy();
			JAXBResponse reqspnse = rspf.Resonse(responseEnity);
			
		}
		catch(Exception e)
		{
			e.printStackTrace();
		}
		
		return reqspnse;
	}

[Junilu Lacar]

I'm going to digress a little bit but please bear with me.

I don't know if you copy-pasted this code or typed it in manually. Line 3 doesn't look like it would compile because there's a stray semicolon between the variable name and the assignment operator. At any rate, the first thing I would do is refactor this code. The names are not good. To be perfectly honest, they are horrible. Names like MyDAO and MyEnity (what's an Enity? Did you mean to type Entity?) are only used in bad example code. Please don't do that in real code. Also, many of these names have spelling errors and missing vowels. This makes the code difficult to read and understand. Take the name agrmntFactory, for example. Is that supposed to be an argument factory or agreement factory or argamont factory?

To illustrate the problem with missing variables and misspelled words: Cna yuo udnrstnd ths sntcne? Wyh do so mny prgrmrs excld vwls frm vrble nms and msspll thm??!

Do you see what I mean? You may be able to make some sense of it and guess what that text means but it takes a bit of effort, doesn't it?

Your code should be readable; that is, when you read it out loud, people shouldn't think that you have some kind of speech impediment. And it's not a valid excuse to say "Well, I didn't write this code." Even if you didn't write it, you certainly should still fix these kinds of problems. You owe it to yourself and other people who will struggle to understand that code later.

the method is not more than 40 line for now

I hope you guys are not planning to add more because 40 lines is already too long for a method.

Now, going back to your question: Does this code look like it belongs in a Facade or Controller?

If those were the only choices, then I would probably lean toward saying it looks like it's code that could be in a Facade. If that sounds noncommittal, that's because it is only based on the code that you posted. I have not seen what else the class that this method belongs to does. Is this the only method in that class? When you say "it connects the dots," what exactly are these "dots" that you talk about?

[Prashant Saraf]

First of all I am so sorry for quality of code. Yes I did typed here. I have some restriction on coping code. But over all your got my point. the connect dot means connect transformer DAO and webservice..
it take input from service imp and send to transformer to create JPA entities. then send those Entity are send to DAO for DB operation. after db operation it call transformer to generate JAXB response. So I am calling it facade.

currently code is not more than 15 line.. I just put 40 line looking into future changes.

Thanks
Prashant Saraf

[Junilu Lacar]

There's no need to apologize about your code here. These are just suggestions to help you and your teammates.

BTW, you really don't have to put "Facade" in the name. The point of a Facade is to hide complex details behind a simpler, easier-to-use interface. The steering wheel on a car is an example of a Facade: it's a simple interface to more complex machinery underneath. But it's still called just the "steering wheel", not the "rack and pinion facade" or the "recirculating ball facade".

The problem with code examples is that the authors often use names with the goal of making the roles of different pieces clear to the reader. That's why you'll see code examples that do include "Facade" in the name but by putting "Facade" in the name of the class, you are, in a sense, creating a "Leaky Abstraction" because you are giving a hint that there is more to this object than meets the eye. If you remove "Facade" from the name, you give the full illusion that the facade is the really all there is to it, just as the "steering wheel" makes us think there's a direct connection to the wheels and that there's nothing more complex in between.

There's another thing about patterns and their names: they are meant to establish a kind of "shorthand" for communication. In other words, the pattern names are themselves abstractions. When people talk about high-level designs, they use pattern names so they don't have to go into the implementation details. So instead of saying, "We're going to set up a producer that will create messages that will be used by multiple consumers and transmitted via a message queue," we just say "We'll use publish-subscribe."