Dear all, I just start to work on the project. And probably, many stupid questions will be posted in the future. Hopefully, I can get some help here. Thanks a lot!! I have a question about the GUI requirement now. Here is the requirement. "Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs." I guess it means I need to use MVC, but I am not sure about it. Can anybody give me a hint about it? I don't have much experience about GUI. Thanks, Joe
Hi Vlad, Thanks for the reply! I didn't notice there is a post with the same question as mine. So I guess it means, for my project, I need to pay more attention to the GUI design, is that right? I am weak on that...
Hi Joe, Your GUI is only worth about 10%, so don't get too hung up about it. My comments were only designed to show the sorts of things you could think about. The main thing is to ensure that you do not make it difficult for future enhancements to be made. And you are quite right - using MVC is a very good idea, as it helps separate the view from the model, allowing some enhancements to be transparent. Regards, Andrew
Hi Andrew, Thank you for the suggestion!! You are right, the GUI is about 10% of the total score. But I need to spend more time on the design to think about how to make the GUI more extensible, since I have only a little bit experience on it. I have another question for the General Considerations (100 points), what will be those general considerations, since there are already six parts (doc, OO, GUI, Locking...) for the marking? Thanks a lot! Regards, Joe
Hi Andrew and Vlad, For the instruction on GUI, how about apply the design pattern of Factory Method to my GUI implementation? The book of Applied Java Patterns said it is good for creating a extensible framework. (I am new to the design patterns. ) Thanks, Joe
Hi Joe, I did use a factory on my client side application. Many design patterns can be used in this assignment (funny how design patterns seem to work in so many places ), but don't go trying to force a pattern into your design just because you have heard it can be beneficial. You need to determine whether it will be benificial for you. So I cannot simply say "yes, use a factory" - I would have to hear where you are planning on using, what you are hoping it will give you, before I could comment on whether it is a good idea or not. Regards, Andrew
Hi Joe, One thing I should have said: usually design patterns are incorporated into applications in the totally opposite way. That is, you are looking at a design, and you say "oooh, I need to hide the actual implementation of the class(es) that may be used from the class using them, and I want an extensible framework for adding different implementations without changing existing code: sounds like a job for a Factory Pattern" So it is a case of recognising the elements that will work well in a given pattern, then designing them that way. It is not a case of trying to use a pattern because it has been defined. Regards, Andrew