Hi there, In the "Overall Architecture" section in the instructions.html, it says that "the remote client code that you write must provide all the public methods of the suncertify.db.Data class." Why is this requirement? Is it for the situation where client searches the database via local connection: where GUI talks to the remote client, which accesses the db.db file directly and locally. While in a remote db connection mode, the remote client only gets a reference to Data. In my design, I have two packages suncertify.client contains GUIs, DBClient (the remote client); suncertify.db contains DBConnectionFactory, Data Based on the connection mode chosen by the user, my DBClient either obtains a remote reference to Data (in remote db mode), or it uses its implementation (which is identical of that in Data) of all the methods of Data (in local db mode). I'm not sure that I understand the requirement listed above. Does my implementation make sense? Any help would be appreciated. Thanks!
basically to fulfill this requirement you will create an interface that has all these public methods of Data, you can have Data then implement it, since it already have the methods. Also you can create two implementations of this interface. One for local mode and one for remote mode. Later on for the client to hide the "complex" implementation of the local or remote classes you can wrap this interface into a Facade class so that the client actually only calls methods like bookFlight(), searchFlight etc. I think they have this requirement to steer you towards this kind of implementation, which is a very clean design. Hope that helps Mark
Thanks, Mark! So it seems that you need to have two clases that both have the same set of methods of Data: one for local db connection and the other for remote connection, only with minor difference such as that in constructors. That's why the requirement for "the remote client" must provide all the public methods of Data. In this case, you can make either Data or "the remote client" to address one connection mode, and the other to address the other connection mode. Am I right? As for the Facade pattern, it can be useful to deal with the complexity resulted from having the two types of connection modes/classes. But having two classes that implement the same set of methods in an almost identical way (except in constructors in my implementation) does not sound right to me for a good OO design. Am I right or have I missed anything? Thanks.
Well the Facade does hide the local or remote implementation from the client, so the client doesn't care or need to know whether it is local or remote mode. And the client thinks in terms of bookFlight(), searchFlight(), fillComboBoxes(). The client should not think in terms of lock(), unlock(), readRecord(), deleteRecord() this brings many great benefits of OOP.
here the client only deals with one class the Facade at all times. Mark
Joined: Mar 17, 2003
Thanks again, Mark! I can clearly see the benefits of using the Facade pattern in this case. But what I am worried is that both my Data and "the remote client" have the same set of methods and almost identical implementations (LocalDataImpl and RemoteDataImpl in your diagram). Should I be concerned? Thanx.
Hello. Regarding the Facade having methods like bookFlight and searchFlight, I disagree with it. As far as I know, the Facade is suposed to be a generic implementation for a complicated interface and by putting the bookFlight and searchFlight in the Facade class we are turning this class into a usable class only for Fly By Night. My idea of a facade implementation is a class that has methods like read, write, modify and others related to database access but that can be called in a simpler way and can be used by several applications. For example, in the Data class you have the method getRecord(int), but in the facade you could have a readRecord(String) that will call the find in the Data to obtain the record number and after this will read that record. You then will have a model class to act in your MVC implementation and that class should be a specific class to deal with the requirements of the FBN application. At least this was the idea that i've get from "The Design Patterns Java Companion" book. Miguel
In both the Design Patterns books, the one by the Gang of Four, and the Java Companion, the way I described it is what a Facade class is. It is not supposed to be a generic class that can be used elsewhere, except for using with Fly By Night. It is not a Wrapper class like some where there is reusablility. In both cases it is still an accurate use of the Facade pattern. Also Allison, yes both implementation classes are pretty close in code. But still there are differences. More so in my submission, but that shouldn't mean anything. Mark
Regarding the Facade having methods like bookFlight and searchFlight, I disagree with it. As far as I know, the Facade is suposed to be a generic implementation for a complicated interface and by putting the bookFlight and searchFlight in the Facade class we are turning this class into a usable class only for Fly By Night.
I competely agree with Miguel. The bookFlight() and searchFlights() methods belong to Model. The Model itself can make use of DatabaseFacade to simplify the access to database (the facade would have methods such as getUniqueFieldValues(int field) or getFieldForPrimaryKey(String key, int fieldNum), but don't mix the responsibilities of these two different classes. When you have a class that has methods such as getCustomerLastName() and getNextPrimeNumber(), you should sense that something is wrong. Eugene. [ March 17, 2003: Message edited by: Eugene Kononov ]
Joined: Mar 17, 2003
I tend to agree with Mark on the point of Facade primarily based on the "compiler" example given in the book by the Gang of Four on Facade. The Compiler class provides the user with a simple method of compile(), which uses classes and methods of the subsystems, e.g. scanner, parser, etc. In our case, searchFlight() and bookFlight() are those methods just like compile() in the Compiler class. If the Compiler class can be called a Facade, then the class that provides serachFlight() and bookFlight() can be called a Facade too, a database Facade. Agree? There may be other ways of using the Facade pattern, but such implementation described by Mark is sound.
Thanks Mark for addressing my concern of code similarity between Data and "the remote client".
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: remote client provides methods of db.Data?