*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Extending vs Modifying the Data class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Extending vs Modifying the Data class" Watch "Extending vs Modifying the Data class" New topic
Author

Extending vs Modifying the Data class

James Du
Ranch Hand

Joined: Mar 23, 2001
Posts: 186
Hi,
Now i am at the stage of making documents and have been bogged down for several days.
I choosed modifying the Data class, but i really cant find out any cogent arguments to defend it. I cant see there's many advantages in modifying the calss than extending it, neither extending than modifying. i think either approach is acceptable and choosing this or that is just a very natural thing, doesnot involve much struggle. wonder why SUN attach so much importances on this point?
another problem, in some main aspects of the assignment such as Server Design and Client Design, I think something shoud be stated in the design choice file, but i really cant figure out what to say and how to start! What do you guys state in this aspect?
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
For client design, you could write about how you implemented MVC, why you used combo boxes or text fields to enter search criteria, why you did or did not use a GUI to select local/remote mode, host and port,...etc.
James Du
Ranch Hand

Joined: Mar 23, 2001
Posts: 186
Thanks Robin
How about extending vs modifying the Data class?
Regards
James
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
I'm having a hard time coming up with reasons to modify since I chose to extend. I guess you could say it is less complicated, and has better performance since there is less object creation.
[ July 21, 2002: Message edited by: Robin Underwood ]
arun s kumar
Greenhorn

Joined: Jul 23, 2002
Posts: 5
Are synchronized methods from Data class inheritted when it is subclassed?
Eduard Jodas
Ranch Hand

Joined: May 14, 2002
Posts: 80
I also have modified the Data class. My reasons were:
* I think locking and searching are basic capabilities of a database. A database without them is quite useless
* Performance: if extending I can only use the Data public/protected interface. On the contrary, if modifying I can access private fields/methods that can make criteriaFind much faster
* Bug hunting: Data's javadoc was wrong, and some methods had bugs. So I had to modify Data anyway.
As an example:
Client Design:
* MVC? Yes/No Why? How?
* Facade to access the server?
* How did you deal with remote/local connection? Did you have a unique interface? Did you use Strategy pattern? How about RemoteExceptions?
* Multithreaded client?
* Exception handling/mechanism
* comboboxes or textfields? hardcoded airports, database read airports or nothing?
* search criteria: origin plus destination airports, or added carrier or more?
* internationalization?
Server design:
* locking mechanism:
- lock manager: yes/no
- how to identify client
- lock implement in local mode/remote mode
- database locking: lock(-1) / unlock (-1)
* exception handling/mechanism
* RMI vs sockets
* How do you deal with dead clients? Unreferenced?
* is your server capable of using one database or multiple databases?
* deadlock prevention
* did you use a Factory pattern to create connections?
* criteria find implementation
* Did you use a policy file? why?
* How did you deal with deprecated methods?
James Du
Ranch Hand

Joined: Mar 23, 2001
Posts: 186
Thanks Eduard,
Your input is highly appreciated, they do give me a inspiring idea to start.
Could you elaborate the Strategy pattern you mentioned a little more? I never see someone use the pattern in the assignment, what's it for?
Regards
James
Eduard Jodas
Ranch Hand

Joined: May 14, 2002
Posts: 80
From "The design patterns Java companion" by James W. Cooper:
[The Strategy pattern is much like the State pattern in outline, but a
little different in intent. The Strategy pattern consists of a number of related
algorithms encapsulated in a driver class called the Context. Your client
program can select one of these differing algorithms or in some cases the
Context might select the best one for you. The intent, like the State pattern, is
to switch easily between algorithms without any monolithic conditional
statements. The difference between State and Strategy is that the user
generally chooses which of several strategies to apply and that only one
strategy at a time is likely to be instantiated and active within the Context
class. By contrast, as we have seen, it is likely that all of the different States
will be active at once and switching may occur frequently between them. In
addition, Strategy encapsulates several algorithms that do more or less the
same thing, while State encapsulates related classes that each do something
somewhat different. Finally, the concept of transition between different states
is completely missing in the Strategy pattern.]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Extending vs Modifying the Data class
 
Similar Threads
document in the final submission jar!!!
Extending vs. Changing the Data class
Design Choices document
modifying vs. Extending the Data class
FBN: Modifying vs. Extending the Data class