fxbird wrote:I didn't see anything wrong with your questions.EJP wrote:If 'R u ...' is a implite manner ,I would like apoligize , cause I'm not from a English-speaking country, though I've been studied English, sometime I still can't express what I really want to say as exactly. If that's not the reason, I want to say, I'm here to ask for helps, I'm not gonna ask meaningless questions, I do not want to waste time of anybody. So I can't agree with you about what you said. How do you think that's a meaningless question? Your reply was so short that I just can't understand . Maybe you could give me some advices about how to ask meaningful question kindly.R u saying it uses abstractiong hierarchy in other language sense? say C++.A tip for future reference. Whenever I see a question that starts 'so are you saying' I have found that the answer is invariably 'no'. So when you find yourself about to ask such a question, think again.
In this case it is 'no' because your question is meaningless. 'Abstraction in the C++ sense' is identical to 'abstraction in the Java sense'.
Possibly I should have said 'abstraction in the OO sense'.
Or possibly you shouldn't ask meaningless questions.
jschell wrote:Thank jschell for your patient reply. What I refered to 'common' is bridge pattern can be seen in almost every jee project in my country,China. Every textbook uses that method to make a jee project. But I still fail to find a good sample explaining the bridge intent behind and how implementor and abstraction hierarchy varies indepently? Here is a sample, [http://en.wikipedia.org/wiki/Bridge_pattern] , but it can not explain very well , cause in CircleShape, it act just like another client, simply invoke a proper Drawing implementor, such things can be done client, real client, why would use CircleShape still? It doesn't do more than the client code.fxbird wrote:You phrased your comment about J2EE. A common idiom is to refer to a J2EE (actually newer name is JEE) server as a JEE container. Not sure why specifically that word is used but maybe because such servers are said to 'contain' applications.jschell wrote:Hello jschell , what do you mean by 'container'?fxbird wrote:Certainly isn't if someone is using a container.
I think it's very common in j2ee development.
If someone is creating a container then I would suspect that such a pattern might be useful.
However if someone is creating a container then there are going to be a lot of useful patterns. And lot of classes as well.
And in total of the entire scope of creating a container the bridge would be a very small part.
So it certainly isn't going to be "common".
In my previous reply, the architecture I mentioned is ss(spring+struts2.x),the pattern I mentioned is a standard way.You either do not understand what I said or you do not understand what happens in those implementations.
If I have 100,000 classes and 3 of them are implementing the bridge pattern then it is not "common".
If I have 100,000 classes and 3,000 of them implement many bridge patterns (and not generated) then one could say it is "common".
And having done some JEE applications I seriously doubt there is an implicit need to use the bridge pattern.
The bridge pattern is intended to deal with a complex situation. Since there are more simple JEE applications than complex ones then it seems unlikely that there is a "common" need for it in JEE applications.
Actual I've not been understood why it's used this way---define business interface, from my perspective, it doesn't have to define it, simply writing a business class and calling dao method is enough. I assume bo interface thing is a bridge pattern.I don't know why they would use the bridge pattern nor even if they really do. I wouldn't be surprised that it is used and I can also suppose that the use would be a good idea. Although it is quite possible as well that it is used incorrectly in some places.
EJP wrote:Hello EJP, thank your reply.
The point of the pattern is that one side of the bridge provides an interface contract A while the other side provides an interface contract B. This is what is meant by 'varying independently'.
(Note that I am not specifically talking about Java 'interfaces' here, just generalities. It is used when you don't want one side of the bridge to know about the API on the other side of the bridge.)
In my particular case in 1997, I had to provide a persistent-object interface. The underlying database provided persistent objects and collections via a specific API that I didn't want to expose to the rest of the application, in case we wanted to change database vendors where the new one might expose a different API. So I invented an API of my own that was exposed to the rest of the application, and my bridge-pattern layer handled the mapping between that API and the database's API.
However as I stated above I was far from happy with the solution and I'm practically certain there were better ways to implement it, or at least better ways to express it in code that the way I implemented it.
I've never used or seen the bridge pattern since. I conclude that it is used very rarely indeed in the circles I inhabit.
But we could simply define a interface and make each vendor implement itWhat on earth are you talking about? How exactly is one customer going to force each vendor to implement a customer-defined interface? This is complete fantasy.
the bridge was unnecessary , wasn't it?I don't think you've understood a word I've said in this thread.
EJP wrote:Different database vendor can affect the interface? I mean we should define an interface and write a DAO implementing the interface for different database vendor for tiny sql difference, not to make vendor do the thing, if you mean 'different database, like sql server , oracle ,such difference' by 'different vendor'. I do not think I understand nothing of your words.But we could simply define a interface and make each vendor implement itWhat on earth are you talking about? How exactly is one customer going to force each vendor to implement a customer-defined interface? This is complete fantasy.
Out there in the real world, the vendors implement their interfaces and we, the customers, interface our code to them. In my case via the bridge pattern so that the damage was contained.the bridge was unnecessary , wasn't it?I don't think you've understood a word I've said in this thread.
I mean we should define an interface and write a DAO implementing the interface for different database vendorUp to here you have just described the bridge pattern. An outer interface that remains constant to the rest of the application and an inner interface that hides differences among vendors.