![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
Hi Ranchers,
I�d like to talk about a topic that is still not very clear to me: the code complexity. The specification says that:
To define or understand what complex means is not trivial, because what is very complex for some people is fairly simple for other and vice versa. I would expect that a very complex solution won�t result in an automatic failure but it will drop some points at the General Consideration evaluation, for example. I also believe that a pretty simplistic approach will have a similar result.
My solution for example was quite complex (I didn�t realize that until I read this forum). It had 59 classes, which is quite big if I mention that I used RMI. The total size of my source files was 440KB (unachieved). The design was little bit over complicated because I designed a solution that doesn�t require any code changes if the database schema changes (to mention only one feature that was definitely not required). I also implemented all the methods, including update, insert or delete, up to the user interface. Locking was also little bit more complex than it could be, etc.
Bottom line is that I didn�t lose points at any of the more difficult parts of the assignment, like Locking, Data Store or OOD Design, but I dropped points at the General Considerations (92 out of 100), or the documentation (60 out of 70 � more classes results in more documentation to write, etc.), which usually should help getting a better score.
Here there are the design choices that I suspect led me to losing those points (not sure which of them could be suspected of extra overhead):
I implemented a record object, rather than a simple record structure. My record objects build dynamically based on the database schema. Only this part of the project has 9 files and 70KB. For locking I used a double-locking (terminology is mine) approach: I implemented a Read/Write locking at the file level and a caching mechanism at the record level. The caching was little over complicated because it could be configured (when the server started) to avoid starve to death situation, orphan clients or even cancel the current transaction if the client locks the record more than s/he should. I used a truly MVC pattern to implement the user interface (a simplified model of the Struts MVC implementation for those familiar with the tool). This part also involved 9 file and more than 50K.
If other ranchers find this topic interesting, they could ask other certified developers to write about their experience. I believe it�s very important for people that aim to get certified to define the boundaries between simplistic and complex.
I hope this will help.
Regards.
I�d like to talk about a topic that is still not very clear to me: the code complexity. The specification says that:
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.
To define or understand what complex means is not trivial, because what is very complex for some people is fairly simple for other and vice versa. I would expect that a very complex solution won�t result in an automatic failure but it will drop some points at the General Consideration evaluation, for example. I also believe that a pretty simplistic approach will have a similar result.
My solution for example was quite complex (I didn�t realize that until I read this forum). It had 59 classes, which is quite big if I mention that I used RMI. The total size of my source files was 440KB (unachieved). The design was little bit over complicated because I designed a solution that doesn�t require any code changes if the database schema changes (to mention only one feature that was definitely not required). I also implemented all the methods, including update, insert or delete, up to the user interface. Locking was also little bit more complex than it could be, etc.
Bottom line is that I didn�t lose points at any of the more difficult parts of the assignment, like Locking, Data Store or OOD Design, but I dropped points at the General Considerations (92 out of 100), or the documentation (60 out of 70 � more classes results in more documentation to write, etc.), which usually should help getting a better score.
Here there are the design choices that I suspect led me to losing those points (not sure which of them could be suspected of extra overhead):
If other ranchers find this topic interesting, they could ask other certified developers to write about their experience. I believe it�s very important for people that aim to get certified to define the boundaries between simplistic and complex.
I hope this will help.
Regards.
