NX: Modifying DBMain (but slightly)
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Hi,
Many people consider modifying the DBMain interface, and then ask on
this forum what people think. People then have given their opinions
and their reasoning about why or why not DBMain should not be modified,
and the majority opinion is that DBMain should not be modified.
So, I don't mean to re-invent the question, but I think this particular
question is slightly different.
In order to carry out testing, and this is where my question comes in,
as I'm thinking about leaving this change in the code that I deliver to
Sun, I have made this one change to DBMain:
Original:
My Modification:
The motivation for this change is that I can use one interface type reference:
to test the following scenarios:
1. data refers to SuperDBMain which refers to DBMain which refers to Data.
This is in local mode, as the software only returns a DBMain reference type
when Data is created in local mode. While it's true that SuperDBMain also
potentially throws a RemoteException which must be caught and handled
by the testing code, it is impossible for this impossible for this to be thrown
during testing since Data is locally created.
2. data refers to SuperDBMain which refers to IndependentDataInterface
which refers DBMain2 which refers to Data. This is the local mode wherein
the client gets a local mode to Data through the factory.
3. data refers to SuperDBMain which refers to IndependentDataInterface
which refers to RemoteDataInterface which refers to DataImpl (and DataImpl
delegates all calls to the local (with respect to the server) Data instance. This is the
remote mode wherein the client gets a remote Data object from the factory.
In short, by defining SuperDBMain, in my testing, I can use one reference
type, SuperDBMain, and build under it three, uniquely formed types of "Data"
and use exactly the same test code (for all tests which should not throw
RemoteException).
But, this means that I have modified DBMain to extend SuperDBMain, when
as originally given, the DBMain interface extended nothing. SuperDBMain
does not add anything to DBMain; that is, the examiner can still say:
DBMain data = new Data(...);
and data as so created is not required to catch any RemoteException.
So, the one line of modified code:
has great benefits, but it does, depending on your opinion, break the rules.
What are your opinions? And, what are your opinions if this were the real
world?
I can find no fault with the idea. If I implement Data as an extension of DBMain
as given by Sun, if I then say DBMain extends SuperDBMain, the Data I implemented
remains exactly the same. Based upon this, I'm inclined to think that my idea
of modifying Data to extend SuperDBMain has no real fault to it, but as I might
have missed something, I ask for your opinion.
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
Many people consider modifying the DBMain interface, and then ask on
this forum what people think. People then have given their opinions
and their reasoning about why or why not DBMain should not be modified,
and the majority opinion is that DBMain should not be modified.
So, I don't mean to re-invent the question, but I think this particular
question is slightly different.
In order to carry out testing, and this is where my question comes in,
as I'm thinking about leaving this change in the code that I deliver to
Sun, I have made this one change to DBMain:
Original:
My Modification:
The motivation for this change is that I can use one interface type reference:
to test the following scenarios:
1. data refers to SuperDBMain which refers to DBMain which refers to Data.
This is in local mode, as the software only returns a DBMain reference type
when Data is created in local mode. While it's true that SuperDBMain also
potentially throws a RemoteException which must be caught and handled
by the testing code, it is impossible for this impossible for this to be thrown
during testing since Data is locally created.
2. data refers to SuperDBMain which refers to IndependentDataInterface
which refers DBMain2 which refers to Data. This is the local mode wherein
the client gets a local mode to Data through the factory.
3. data refers to SuperDBMain which refers to IndependentDataInterface
which refers to RemoteDataInterface which refers to DataImpl (and DataImpl
delegates all calls to the local (with respect to the server) Data instance. This is the
remote mode wherein the client gets a remote Data object from the factory.
In short, by defining SuperDBMain, in my testing, I can use one reference
type, SuperDBMain, and build under it three, uniquely formed types of "Data"
and use exactly the same test code (for all tests which should not throw
RemoteException).
But, this means that I have modified DBMain to extend SuperDBMain, when
as originally given, the DBMain interface extended nothing. SuperDBMain
does not add anything to DBMain; that is, the examiner can still say:
DBMain data = new Data(...);
and data as so created is not required to catch any RemoteException.
So, the one line of modified code:
has great benefits, but it does, depending on your opinion, break the rules.
What are your opinions? And, what are your opinions if this were the real
world?
I can find no fault with the idea. If I implement Data as an extension of DBMain
as given by Sun, if I then say DBMain extends SuperDBMain, the Data I implemented
remains exactly the same. Based upon this, I'm inclined to think that my idea
of modifying Data to extend SuperDBMain has no real fault to it, but as I might
have missed something, I ask for your opinion.
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Javini,
Some thoughts about simplicity...
[ March 06, 2004: Message edited by: George Marinkovich ]
Some thoughts about simplicity...
From my assignment instructions:
Clarity and Maintainability
A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient. Code complexity, including nesting depth, argument passing, and the number of classes and interfaces, should be reasonable.
from Sun Certified Programmer & Developer for Java 2: Study Guide (Exam 310-035), Third Edition
by Kathy Sierra and Bert Bates
Write your code as if the person who maintains it
is a homicidal maniac who knows where you live.
And:
The exam assessors aren't thinking like my-algorithm-is-bigger-than-yours code mavericks. They aren't looking for the next great breakthrough in record-locking. They aren't even looking for new, creative implementations. They are looking for development that says, "I'm a thoughtful programmer. I care about maintainability. Readability is very important to me. I want everyone to understand what's going on with the least amount of effort. I write careful, correct code. My code might not be the snappiest, and it might even incur an extra few bytes in order to make something less complex, but my logic is simple, my code and my design are clear and implement the specification perfectly, I didn't reinvent the wheel anywhere, and gosh, wouldn't you just love to have me on your team? If your project submission says all that about you, you're in great shape.
from http://suned.sun.com/US/catalog/courses/CX-310-252A.html
Nature of the assignment
The assignment requires that you write working code for a small but plausible business system. To keep the amount of work involved to a reasonable level, the programs you create will be much more restricted in capability, and much cruder in overall presentation, than anything you would actually create for a paying customer. However, the essence of the problem will be the same. You will be graded on correctly solving the technical requirements, not on the "polish" of the finished product. Note however, that some aspects of ease of use, for example how easily the program may be started or configured, will be part of the scoring criteria. Pay careful attention to any such requirements and be sure to adhere to them.
Scale of the assignment
Obviously, the amount of time taken by a candidate to create a working solution to the assignment varies greatly. Brooks, in "The Mythical Man Month," noted years ago that programmer productivity varies by at least ten-to-one. However, a fast programmer might create a solution in about twenty hours. A more typical expectation of a time requirement might be in the order of a working week. If you spend a lot more than two weeks on the project, you might well be creating something that is more detailed than is really required, and you might want to review the scoring criteria and problem statement provided in the assignment.
Perhaps a more consistent measure of the scale of the assignment might be derived from the average number of lines of code submitted in typical passing assignments. Again, this is subject to substantial variation, but as a guide, 3500 lines of code is a reasonable estimate of the mean size of passing assignments.
[ March 06, 2004: Message edited by: George Marinkovich ]
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Hi,
George, as always, thanks for your comments now and the many comments and
suggestions you have made in the past.
Here is my current design diagram with comments:
The above is an outline.
I'm not showing, for instance, that DBMainPlus extends DBMain and that Data
implements DBMainPlus, as this adds more clutter to the picture, but let it be
assumed that this is the only way to add new, more powerful methods to Data that
were not originally specified within DBMain.
George, based upon your last suggestions, where I had previously said that I
would not allow the examiner to instantiate Data directly, but after your
good ideas, I decided that I would allow the examiner to instantiate Data and
manipulate Data through the DBMain interface, we arrive at the above figure.
There are, of course, three paths the client can use when manipulating the
database:
1. Local: instantiate Data and reference it through DBMain.
2. Local: instantiate Data and reference it through VersatileDataInterface.
3. Remote: instantiate DataImpl (which delegates to Data) and reference it
through VersatileDataInterface.
I take it that so far, the above is not overly complicated, and that it is
essentially required to meet the requirements. If at this stage you consider
things already too complicated and getting out of hand, please let me know.
If we assume that the above is not overly complicated, then I need to test
all three paths, and for testing conditions where a RemoteException is not
thrown, I should be able to use the same JUnit test code. There would be
three major loops for each test: creating the three above stated paths:
1. DBMainSuper --> DBMain --> Data
2. DBMainSuper --> VersatileDataInterface --> DBMain --> Data
3. DBMainSuper --> VersatileDataInterface --> DataRemoteInterface --> DataImpl --> DBMain --> Data
It is this simplicity, the simplicity of testing these three major "pathways"
that I have introduced DBMainSuper, for then the JUnit test code need not
change while each of the three paths are tested, which results in the following
design diagram which only adds DBMainSuper:
As always, George, I appreciate your comments very much. Please let me know
what you think?
Thanks,
Javini Javono
P.S.
Concerning the line of code count, which is a nice, ball-park figure that Sun
has provided, I have
9687 lines of code,
but this figure--based upon my tabs remover application--is over stated since
it includes any .java file, including design ideas that are .java files only
with comments, and utility code I wrote when I first started and which will not
appear in the final project, as well as 400 lines of JUnit testing code which
will quite easily rise to 1,000 or more lines (JUnit really keeps me moving
quickly, and solving issues; I'm quite happy about this new tool).
[ March 06, 2004: Message edited by: Javini Javono ]
[ March 06, 2004: Message edited by: Javini Javono ]
[ March 06, 2004: Message edited by: Javini Javono ]
George, as always, thanks for your comments now and the many comments and
suggestions you have made in the past.
Here is my current design diagram with comments:
The above is an outline.
I'm not showing, for instance, that DBMainPlus extends DBMain and that Data
implements DBMainPlus, as this adds more clutter to the picture, but let it be
assumed that this is the only way to add new, more powerful methods to Data that
were not originally specified within DBMain.
George, based upon your last suggestions, where I had previously said that I
would not allow the examiner to instantiate Data directly, but after your
good ideas, I decided that I would allow the examiner to instantiate Data and
manipulate Data through the DBMain interface, we arrive at the above figure.
There are, of course, three paths the client can use when manipulating the
database:
1. Local: instantiate Data and reference it through DBMain.
2. Local: instantiate Data and reference it through VersatileDataInterface.
3. Remote: instantiate DataImpl (which delegates to Data) and reference it
through VersatileDataInterface.
I take it that so far, the above is not overly complicated, and that it is
essentially required to meet the requirements. If at this stage you consider
things already too complicated and getting out of hand, please let me know.
If we assume that the above is not overly complicated, then I need to test
all three paths, and for testing conditions where a RemoteException is not
thrown, I should be able to use the same JUnit test code. There would be
three major loops for each test: creating the three above stated paths:
1. DBMainSuper --> DBMain --> Data
2. DBMainSuper --> VersatileDataInterface --> DBMain --> Data
3. DBMainSuper --> VersatileDataInterface --> DataRemoteInterface --> DataImpl --> DBMain --> Data
It is this simplicity, the simplicity of testing these three major "pathways"
that I have introduced DBMainSuper, for then the JUnit test code need not
change while each of the three paths are tested, which results in the following
design diagram which only adds DBMainSuper:
As always, George, I appreciate your comments very much. Please let me know
what you think?
Thanks,
Javini Javono
P.S.
Concerning the line of code count, which is a nice, ball-park figure that Sun
has provided, I have
9687 lines of code,
but this figure--based upon my tabs remover application--is over stated since
it includes any .java file, including design ideas that are .java files only
with comments, and utility code I wrote when I first started and which will not
appear in the final project, as well as 400 lines of JUnit testing code which
will quite easily rise to 1,000 or more lines (JUnit really keeps me moving
quickly, and solving issues; I'm quite happy about this new tool).
[ March 06, 2004: Message edited by: Javini Javono ]
[ March 06, 2004: Message edited by: Javini Javono ]
[ March 06, 2004: Message edited by: Javini Javono ]
Satish Avadhanam
Ranch Hand
Posts: 697
posted 13 years ago
Hi Javini, as always, your design and messages are very thought provoking. And at times I feel 
that I don't know anything. Anyways, got a couple of doubts, maybe if you can help in understanding...
To add to Javini's coding concerns, I got a couple more.
1. My Data class is about 1200 lines. Is it ok?
2. Am using many(to say, given interface's methods + 24 more) methods. You
think its not advisable? Or shall I use any helper class to abstract some of the methods. If so, are inner class is advisable for the exam?
Any comments are appreciated. Thanks.
that I don't know anything. Anyways, got a couple of doubts, maybe if you can help in understanding...Originally posted by Javini Javono:
Hi,
George, as always, thanks for your comments now and the many comments and
suggestions you have made in the past.
Here is my current design diagram with comments:
The above is an outline.
I'm not showing, for instance, that DBMainPlus extends DBMain and that Data
implements DBMainPlus, as this adds more clutter to the picture, but let it be assumed that this is the only way to add new, more powerful methods to Data that were not originally specified within DBMain.
George, based upon your last suggestions, where I had previously said that I would not allow the examiner to instantiate Data directly, but after your good ideas, I decided that I would allow the examiner to instantiate Data and manipulate Data through the DBMain interface, we arrive at the above figure.
Javini, are you not using adapter here? I mean, in the local mode it seems you want to send the Data as DBMain as stated in point 1 below. Can you tell me how this is good than using an adapter or if you could point out to George's links where he explained you that would be great.
There are, of course, three paths the client can use when manipulating the
database:
1. Local: instantiate Data and reference it through DBMain.
2. Local: instantiate Data and reference it through VersatileDataInterface.
3. Remote: instantiate DataImpl (which delegates to Data) and reference it through VersatileDataInterface.
Thanks,
Javini Javono
P.S.
Concerning the line of code count, which is a nice, ball-park figure that Sun has provided, I have 9687 lines of code, but this figure--based upon my tabs remover application--is over stated since it includes any .java file, including design ideas that are .java files only with comments, and utility code I wrote when I first started and which will not appear in the final project, as well as 400 lines of JUnit testing code which will quite easily rise to 1,000 or more lines (JUnit really keeps me moving quickly, and solving issues; I'm quite happy about this new tool).
[ March 06, 2004: Message edited by: Javini Javono ]
To add to Javini's coding concerns, I got a couple more.
1. My Data class is about 1200 lines. Is it ok?
2. Am using many(to say, given interface's methods + 24 more) methods. You
think its not advisable? Or shall I use any helper class to abstract some of the methods. If so, are inner class is advisable for the exam?
Any comments are appreciated. Thanks.
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Hi Satish,
Thanks much for responding. Unfortunately, I posted old design
drawings! I've now pasted in the correct and current design
drawings for my project; it's amazing how rapidly things keep
changing.
I don't know if this will change your response or not.
I'll now read your response.
Thanks again for responding,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
Thanks much for responding. Unfortunately, I posted old design
drawings!
I've now pasted in the correct and current designdrawings for my project; it's amazing how rapidly things keep
changing.
I don't know if this will change your response or not.
I'll now read your response.
Thanks again for responding,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Originally posted by Satish Avadhanam:
Javini, are you not using adapter here? I mean, in the local mode it seems
you want to send the Data as DBMain as stated in point 1 below. Can you tell me
how this is good than using an adapter or if you could point out to George's
links where he explained you that would be great.
Hi,
Whether Data internally carries out all its work, or delegates its work does
not alter the design. For instance, in my design, Data delegates all its work
to other objects, which I represent symbolically as one MyDataWorker object.
But, perhaps I have not answered your question correctly? So, let me ramble on
a little bit more here.
Let us, for simplicity, say that an adapter pattern is one where much delegation
is going on. Where, I believe, you mostly here about delegation is when
DataImpl delegates it's work to Data (which occurs in my design above).
DataImpl is a distinct server object, but it contains a unique server-side
Data object. I don't want to place code in two places, so DataImpl delegates
everything to Data on the server.
Concerning a couple other points:
I expose Data via DBMain in case the examiner wants to test it directly,
and, as George said, it is, afterall, a must condition.
The reason that I have the VersatileDataInterface, is so that client code
can be the same regardless of whether or not the connection is local or remote:
wherein the client code is identical for both cases.
A similar situation emerges when I, using JUnit, become the client. I want
to test to the interface, but there is no grand interface to test all three
points of entry. So, I introduce DBMainSuper, and set up the test of all
three branches like this (for testing conditions that don't throw remote
exception):
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
Javini, are you not using adapter here? I mean, in the local mode it seems
you want to send the Data as DBMain as stated in point 1 below. Can you tell me
how this is good than using an adapter or if you could point out to George's
links where he explained you that would be great.
Hi,
Whether Data internally carries out all its work, or delegates its work does
not alter the design. For instance, in my design, Data delegates all its work
to other objects, which I represent symbolically as one MyDataWorker object.
But, perhaps I have not answered your question correctly? So, let me ramble on
a little bit more here.
Let us, for simplicity, say that an adapter pattern is one where much delegation
is going on. Where, I believe, you mostly here about delegation is when
DataImpl delegates it's work to Data (which occurs in my design above).
DataImpl is a distinct server object, but it contains a unique server-side
Data object. I don't want to place code in two places, so DataImpl delegates
everything to Data on the server.
Concerning a couple other points:
I expose Data via DBMain in case the examiner wants to test it directly,
and, as George said, it is, afterall, a must condition.
The reason that I have the VersatileDataInterface, is so that client code
can be the same regardless of whether or not the connection is local or remote:
wherein the client code is identical for both cases.
A similar situation emerges when I, using JUnit, become the client. I want
to test to the interface, but there is no grand interface to test all three
points of entry. So, I introduce DBMainSuper, and set up the test of all
three branches like this (for testing conditions that don't throw remote
exception):
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
Satish Avadhanam
Ranch Hand
Posts: 697
posted 13 years ago
Hi Javini
Please let me know if I'm wrong. Thanks.
Originally posted by Javini Javono:
Hi,
Whether Data internally carries out all its work, or delegates its work does not alter the design. For instance, in my design, Data delegates all its work to other objects, which I represent symbolically as one MyDataWorker object.
I'm also thinking about using an internal class in Data as it has almost 30 methods and about 1100+ lines. I think the number of lines should'nt be a problem as Sun says upto 2000 is OK.
But, perhaps I have not answered your question correctly? So, let me ramble on a little bit more here.
Let us, for simplicity, say that an adapter pattern is one where much delegation is going on. Where, I believe, you mostly here about delegation is when DataImpl delegates it's work to Data (which occurs in my design above).
DataImpl is a distinct server object, but it contains a unique server-side
Data object. I don't want to place code in two places, so DataImpl delegates everything to Data on the server.
Am also doing something same. But let me tell you about my design in brief.
I have introduced new interface DataAccess which has only two business specific methods required for client. DataImpl implements this interface and has reference to Data. At the server, RemoteDataAccess extends DataAccess and Remote. RemoteDataImpl implements this remote interface and UnicastServerObject. Also there is connection factory logic going on...
So as yours, client has reference to DataAccess only. He don't know whether he is making local or remote calls.
If you see anything doubtful or wrong in my design, please let me know.
Concerning a couple other points:
I expose Data via DBMain in case the examiner wants to test it directly,
and, as George said, it is, afterall, a must condition.
Is this a MUST condition. I could'nt see in requirements. Maybe is it because the grader has to test all the other functinality that we provided in Data as they are not used in GUI? Am I right? To say, it is provided so as the grader has to test it whether all our Data methods can really work or not?
The reason that I have the VersatileDataInterface, is so that client code
can be the same regardless of whether or not the connection is local or remote:
wherein the client code is identical for both cases.
A similar situation emerges when I, using JUnit, become the client. I want
to test to the interface, but there is no grand interface to test all three
points of entry. So, I introduce DBMainSuper, and set up the test of all
three branches like this (for testing conditions that don't throw remote
exception):
Thanks for sharing the way you are testing.
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]
Please let me know if I'm wrong. Thanks.
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Is this a MUST condition. I could'nt see in requirements. Maybe is it because
the grader has to test all the other functinality that we provided in Data as
they are not used in GUI? Am I right? To say, it is provided so as the grader
has to test it whether all our Data methods can really work or not?
Hi,
You will have to read over your particular assignment, but, all things being
equal, it probably is a must condition for you also. See this post:
http://www.coderanch.com/t/185214/java-developer-SCJD/certification/Javini-Design
Thanks,
Javini Javono
Is this a MUST condition. I could'nt see in requirements. Maybe is it because
the grader has to test all the other functinality that we provided in Data as
they are not used in GUI? Am I right? To say, it is provided so as the grader
has to test it whether all our Data methods can really work or not?
Hi,
You will have to read over your particular assignment, but, all things being
equal, it probably is a must condition for you also. See this post:
http://www.coderanch.com/t/185214/java-developer-SCJD/certification/Javini-Design
Thanks,
Javini Javono
Satish Avadhanam
Ranch Hand
Posts: 697
posted 13 years ago
Thanks Javini for pointing to the link. I read Ken's design notes too, it was very helpful. I remember that Ken did not expose Data to client. He used an adapter in between Data and client(Remote/Local) and client has no idea of whether a Data is used in his adapter class. My design is also on the same grounds with some variations.
Thanks.
[ March 06, 2004: Message edited by: Satish Avadhanam ]
Thanks.
[ March 06, 2004: Message edited by: Satish Avadhanam ]
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Satish,
1. My Data.java file is 1354 lines (about 998 lines of code including comments), so 1200 sounds good to me.
2. I'm using 34 methods (including the interface methods) in my Data class. Using helper classes is probably a good thing. I used some helper classes (Header and MetadataInfo) for Data, but no inner classes. Inner classes were very helpful in my GUI code.
In general I'm less concerned that a class have many methods than I am that no individual method be very large (in excess of 150 lines). The helper classes are great for abstracting out complexity from the Data class. If I had to do it all over again I think I would have done all the raf file manipulations outside of the Data class in helper classes. That would have made the Data class much more understandable and much smaller.
I hade a GUI class that had 1535 lines in it. I should have refactored that class, I would say that 1500 (physical lines) should be a hard limit or 1000 (LOC plus comments) whichever comes first. When it comes to code, smaller is better.
Originally posted by Satish Avadhanam:
To add to Javini's coding concerns, I got a couple more.
1. My Data class is about 1200 lines. Is it ok?
2. Am using many(to say, given interface's methods + 24 more) methods. You
think its not advisable? Or shall I use any helper class to abstract some of the methods. If so, are inner class is advisable for the exam?
1. My Data.java file is 1354 lines (about 998 lines of code including comments), so 1200 sounds good to me.
2. I'm using 34 methods (including the interface methods) in my Data class. Using helper classes is probably a good thing. I used some helper classes (Header and MetadataInfo) for Data, but no inner classes. Inner classes were very helpful in my GUI code.
In general I'm less concerned that a class have many methods than I am that no individual method be very large (in excess of 150 lines). The helper classes are great for abstracting out complexity from the Data class. If I had to do it all over again I think I would have done all the raf file manipulations outside of the Data class in helper classes. That would have made the Data class much more understandable and much smaller.
I hade a GUI class that had 1535 lines in it. I should have refactored that class, I would say that 1500 (physical lines) should be a hard limit or 1000 (LOC plus comments) whichever comes first. When it comes to code, smaller is better.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Satish Avadhanam
Ranch Hand
Posts: 697
George Marinkovich
Ranch Hand
Posts: 619
posted 13 years ago
Hi Javini,
I'm OK with your design up to this point, but I'm not liking the DBMainSuper because basically it only exists so that you can support a test. By the way I don't think you even need it to do the test, you can test the three major pathways separately rather than require the DBMainSuper interface.
Also, I'm of the opinion that you should not submit test code. I don't think the examiner wants to see test code. I kept my test code in suncertify.test package and didn't include that package in my submission. If you absolutely think you need DBMainSuper interface maybe you can keep it in your equivalent of the suncertify.test package. Of course, if you're determined to submit your test code along with project then I guess it doesn't matter that DBMainSuper only exists to support testing.
Originally posted by Javini Javono:
If at this stage you consider
things already too complicated and getting out of hand, please let me know.
I'm OK with your design up to this point, but I'm not liking the DBMainSuper because basically it only exists so that you can support a test. By the way I don't think you even need it to do the test, you can test the three major pathways separately rather than require the DBMainSuper interface.
Also, I'm of the opinion that you should not submit test code. I don't think the examiner wants to see test code. I kept my test code in suncertify.test package and didn't include that package in my submission. If you absolutely think you need DBMainSuper interface maybe you can keep it in your equivalent of the suncertify.test package. Of course, if you're determined to submit your test code along with project then I guess it doesn't matter that DBMainSuper only exists to support testing.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Javini Javono
Ranch Hand
Posts: 286
posted 13 years ago
Hi George,
Thanks again for your thoughtful responses.
Given your response, I probably will not submit DBMainSuper
to Sun, but use it during JUnit testing. It is trivial to change
DBMain so that it does no extend anything.
Thanks,
Javini Javono
P.S.
Also, I have recently decided that I probably will not submit
any testing code either, but design it and implement it, so
that the system can test itself, but leave this class out when
I submit; the reason being your given reason (it is more work
for the examiner), and another reason that it will bloat my submittal.
Thanks again for your thoughtful responses.
Given your response, I probably will not submit DBMainSuper
to Sun, but use it during JUnit testing. It is trivial to change
DBMain so that it does no extend anything.
Thanks,
Javini Javono
P.S.
Also, I have recently decided that I probably will not submit
any testing code either, but design it and implement it, so
that the system can test itself, but leave this class out when
I submit; the reason being your given reason (it is more work
for the examiner), and another reason that it will bloat my submittal.
