• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Code complexity

 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:


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):

  • 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.
     
    Cob is sand, clay and sometimes straw. This tiny ad is made of cob:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic