Jacob Bridge

Hi,

thank you very much for the answers!

I agree with you about documenting during development, at least for choices.txt. I actually wrote this documentation during development. But I wrote brief description of a problem and my solution for each decision, in order not to forget to document it later in choices.txt.

Sorry, but I still don't understand how you document such decisions. Do you think it's Ok to write that "I think that this task is out of the scope" or it's better to argument this decision according to instructions.html? I mean find different clues in instructions in order to prove that this task out of scope? For example I can write in choices.txt:

------------------------------------------
... Since B&S intends to use that system as a learning exercise before going on to a web based system, client crushes handling is goes out of scope of the assignment. Web based system most probably will require another algorithms for handling client crushes. The implementation of this algorithm will also raise the complexity of the code, that will be bad for understanding it by junior programmers ....
------------------------------------------

Jeffry, had you also decided to not to handle client crushes? How do you described this (or maybe some similar decision)?

Thank you in advance.
And, of course, all you comments are highly appreciated!

Hi,

I starting with final stages of my assignment - documentation. And I have question about choices.txt.

I have some things, that I decided to describe in choices.txt rather than implement them. One of them is Client crushes handling.
I believe, that this implementing this task is out of the scope of the assignment.

And my questions are:
What is the best way to describe such decision choices.txt?
How do you describe such decisions?
Do you think it would be Ok to directly say that "I think that this task is out of the scope"?

What do you think about the following schema of describing such decisions:

-----------------------------------------------------------------------
Problem: problem description...
Possible solutions: we can make this (solution #1) or we can implement it in that way (solution #2)...
Decision: I think, that this task is out of the scope of the assignment, so the solution of this problem is not implemented by me,
but if company's IT director will decide make new project iteration, than I think that solution #1 is the best for solving this problem.
-----------------------------------------------------------------------

looking forward to your comments!
Thank you in advance!

hi Mohamed Sulibi,

thank you for the answer and your opinion.

I agree with you, and in real life I would also create assessor methods instead of constructor args (in real life I actully would use springframework to inject all my dependencies). But I don't want to create defaults, at least for dao, mostly because in this case my Data class will need to know the location of database file in order to get instance of DAO object. But for LockManager it's ok, I think.

Hi!

I want to use dependency injection pattern in my assignment. So that my Data class wild contain such constructor

public class Data implements DBAccess { private LockManager lockManager; private DataAccessObject dao; public Data(LockManager lockManager, DataAccessObject dao) { this.lockManager = lockManager; this.dao = dao; } .... }

during startup of the application all dependencies wold be injected, like this:

LockManager lockManager = new LockManagerImpl(); DataAccessObject dao = DataAccessObjectImpl.getInstance("db.db"); DBAccess db = new Data(lockManager, dao);

and finally my DataAccessObjectImpl (please, notice that it's constructor would be private):

public class DataAccessObjectImpl implements DataAccessObject { private static Map<String, DataAccessObjectImpl> DAO_INSTANCIES = new HashMap<String, DataAccessObjectImpl>(); public static DataAccessObject getInstance(String fileName) { DataAccessObject dao = DAO_INSTANCIES.get(fileName); if (dao == null) { dao = new DataAccessObjectImpl(fileName); DAO_INSTANCIES.put(fileName, dao); } return dao; } ... }

As you can see only one DAO instance would be created for one db file.
(I also plain to add ShutdownHook (Runtime.getRuntime().addShutdownHook(...)) during startup on order to close RandomAccessFile during shutdown, and it will use the same getInstance(..) method of DataAccessObjectImpl to receive appropriate DAO instance)

And here are my questions to you:

- What do you think about using dependencies injection in current situation? Do you think that Sun assessors will accept such solution (I afraid because in this case I don't have defult constructor in Data class)?
- Do you think it's good Idea to use getInstance() method in DAO, or it's better to instantiate DAO directly in the Data class constructor?
- Do you think that provided solution is too complicated and would cause frustrations to junior java developer?

I would be happy to know your opinion about this solution and your comment are highly appreciated!
Thank you in advance!