Design Patterns in my design after refactoring the server side classes, advice needed.

[Jianping Wang]

So I will have a Server class as Facade, to startup, shutdown and provide GUI when database information missing in property file.
Inside the Server class, Proxy for BookingManager, this is to let remote and local client use the actually the same "real" BookingManager.
Factory Method is adopted to create remote or local BookingManager based on argument passed in.
Between the Data class and RandomAccessFile, I have DBAccessor, this class directly access RandomAccessFile according to DataSchema class which is generated by calling parse(String file, int magicCookie) method of DataFileFormat class.

DBAccessor, DataSchema and DataFileFormat are in the same package. NO Design pattern for this three classes. No idea what to use. DataSchema and DataFileFormat is learnt from DateFormat and Date class.

Advices are welcomed!

[Roel De Nijs]

Don't overuse/abuse design patterns! Not each class must have another design pattern. I just used the singleton design pattern for my Data class. And at the client-side I use Observer design pattern and MVC pattern. I believe that's just all the design patterns I used in my assignment. Maybe I forgot one (because I used it unintentionally), but that's really it.
Seems to me you are overcomplicating your solution a lot, just to be able to add every design pattern you know of (or you have read about in head first design patterns). Just keep it easy and simple.

[Raf Szczypiorski]

Is using design patterns an aim in itself? They are here to help, not to be used for every single class. If you don't see them in your design, just don't use them, don't force them in.

[David Kachen]

Hi all,

Everything should be simple and clear. First and foremost, you must know yourself what you did and why.
If you do not see that in this situation you can apply any pattern, then you should not try to pull something special. You can easily make a mistake somewhere.

[Jianping Wang]

So you mean I've been poisoned by Design Patterns?

Facade is used for startup and shutdown, just like a computer box, with a button to startup or shutdown things inside. This is used to close RandomAccessFile and to unbind RMI Registry and also provide GUI to point to database file location.

Proxy Pattern is a wrapper class implements Remote interface and referencing the "real" BookingManager which actually be used locally.

Factory method is for creating a RemoteBookingManager proxy or a local BookingManger depending on argument "server" or "standalone"

I introduced DataSchema class because DataAccessFile operating on bytes. So to retrieve record, we need header size, row size and record flag size, field size. All this information is what Data class need to handle database.

Singleton as Roel mentioned, must be used in my case for Data class

So I have good reason to use them. The trouble is I have to be concise in my design.

Do you provide separate GUI for server to reference database file?

[David Kachen]

Hi Jianping,

My project contains the one universal settings dialog and I use him for server, client and standalone mode.

Best regards..

[Roel De Nijs]

I too have a GUI for entry of configuration settings, starting and stopping my server. A part of this GUI is reused in the client application.

[Jianping Wang]

We are different by how we seeing things in the world. We are actually kind of philosophers. I see BookingManager and Admin in use case. Each of them has a list of services. I know Roel see Services, so the Services can contain a list of services. So the different is I introduced Roles in my design and found that a lot of things are unsure.
Do we need to introduce Roles into our desgin? Because the use case shows who do what, then Roles step in. I introduced Admin because I don't want clients shutting down our RMI server.
If the requirement provides a use case diagram, then we all on the same page now.

[David Kachen]

Hi Jianping,

Correctness
Your project must conform to this specification. Features that deviate from specification will not receive full credit. You will not receive extra credit points for work beyond the requirements of the specification.

Network Approaches
...
No authentication is required for database access.
...

"Introduce Roles" it is a kind of authentication. In this case the user must specify his role.

[Roel De Nijs]

Jianping Wang wrote:I introduced Admin because I don't want clients shutting down our RMI server.

That's where you are wrong! You don't want clients shutting down the RMI server, but I don't have no such requirement in my instructions. So why implement a bunch of functionalities which are not required? And loose a lot of valuable time doing so. How more code you have, how more bugs could be introduced. And you won't get extra credit
And on the other hand: a client can't shutdown the rmi server from a client application. To shutdown the RMI server you have to be at the computer where the RMI server is running on and I guess in any decent company the server room will only be accessible by system admins.

[Raf Szczypiorski]

This would mean that you expose the close method on the RMI Remote interface? I think this is plain wrong - you should only be able to close the server on the machine it is being run on, either locally or just log in using SSH and close it remotely. No client should have the option to call the close method. Let alone what Roel said - you just have a lot of functionality that is not really necessary for the project and makes it more complex. Aggreed, it might be a valuable experience, but I think experimenting with the requirements is not what you should do to get this certification.

[Jianping Wang]

I agree!!! So I chop off Admin things.

So what about my Proxy Pattern. I think it is perfect there: my RemoteProxyBookingManager class implements Remote and BookingManager interfaces, and references local BookingManagerImpl. My BookingManagerFactory create a manager according to the mode (server or standalone).

The good thing about this pattern here is I only create one local class BookingManagerImpl. And the Proxy class just provides RMI functionality for BookingManagerImpl.

[Roel De Nijs]

Jianping Wang wrote:The good thing about this pattern here is I only create one local class BookingManagerImpl. And the Proxy class just provides RMI functionality for BookingManagerImpl.

You could use such an approach as long as you don't break any must requirement, so when running in standalone mode the networking must be bypassed completely. Just mention in your choices.txt why you have chosen this design pattern and its added value (advantages).
Just 1 remark about the name of your classes: now it's called BookingManager, but what will you do if you have to add other management functionalities to your client and server application (e.g. creating new rooms, deleting existing ones, unbooking, updating other fields of a room)? Will you create another specific manager (interface and/or class) or just add these business methods to BookingManager. If you opt for the last one, then BookingManager may be not the most appropriate name

[Jianping Wang]

You are right, So I rename it to BusinessManager, that's bulletproof.

[Roel De Nijs]

I would suggest something like RoomManager (or ContractorManager), because if you have to create similar functionality for customers, you then will create a CustomerManager.

[Jianping Wang]

Hi Roel,

Somehow I begin to doubt this xxxManager naming convention. Using xxxServices is much better. for example CustomerServices, RoomServices. RoomServices has larger scope than RoomManager, it includes all kinds of services related to Room, but RoomManager only include management of room as RoomManager.

[Roberto Perillo]

I guess the most important thing is to name the class according to what it represents... I also think that "services" is a better name for the class.

[Roel De Nijs]

Jianping Wang wrote:Somehow I begin to doubt this xxxManager naming convention.

I also use xService, I was just continuing on the names you used. And my remark made you think a bit further, so mission accomplished

[Jianping Wang]

Thank you both!!!

the most important thing is to name the class according to what it represents

I gonna redesign my assignment according to this principle. I will not stop redesigning until finding out a clear and accurrant way of designing top level OO application!!!