School of computer science and informatics, cardiff university

Best Practice

1. 
   Classes should only have information necessary to their responsibility, and should be restricted to one use only. For example, classes involved in listening for user actions should be separated from code for the user interface.
   
2. 
   Exceptions, which are detectable, must be handled correctly and consistently
   
3. 
   Use of object-oriented programming’s inheritance property should be made use of, when appropriate. This allows for a reduction in repeated code and promotes reuse.
   
4. 
   Information hiding should be maintained, protecting autonomous objects from external classes and methods [31], restricting against unintended changes.
   
5. 
   Polymorphism should be promoted, where appropriate, allowing for the ability to replace an object with its sub-objects
   
6. 
   Use of dependency injection; if an instance of an object is required, it should be injected through method parameters, rather than creating one internally
   
7. 
   The passing of sensitive information should be through classes and not directly, such as through arrays. This makes the program more secure.
   
8. 
   Classes should be open for extension, but not for modification
   

1. 
   Since aspects are very similar to classes [22, 37], an aspect should only be responsible for one crosscutting concern, but may include a number of pointcuts if required.
   
2. 
   The keyword “privileged” should not be a default, and should only be used if necessary. [18] For example, the extension of a class and use of inter-type declarations would be an appropriate use of this keyword. This avoids unintended changes to the source code and invalid access to variables.
   
3. 
   Reuse should be encouraged, through the use, for example, of abstract aspects [13] and wildcard fields.
   
4. 
   Package any aspects used in packages with relevant Java classes, for example, any SQL related aspects should be inside a package with classes querying the database. This promotes dependencies of aspects being placed in similar packages. [37]
   
5. 
   Whilst being mindful of guideline III, wildcards in pointcut designators should be used only when appropriate, to prevent unintended errors such as advising incorrect join points.
   
6. 
   Avoid, where possible, two pieces of advice being executed for the same pointcut, to both promote reusability [14] and avoid confusion when introduced to survey responders. Note that there may be behaviours that require this.
   

1. 
   Protect the system against SQL injection attacks, through the use of prepared statements.
   
2. 
   Avoid redundancy within the database but promote normalisation [32], where a single piece of information should be in only one place in the database.
   
3. 
   Divide data into subject-based tables, whilst avoiding more than one use for one table, e.g. storing a staff member’s password with the rest of their details.
   
4. 
   The database must be external, for security reasons.