Code Design Habit Checklist

Good design is not simply following a formula. In this class, you will be asked to design code that has three basic characteristics:

1. Easy to understand
2. Classes have small, useful interfaces
3. Avoid duplication of all kinds

Within this basic structure, we will have some "rules" that you should work to develop into habits so you can spend more of your intellectual effort solving interesting design challenges.

These will not cover every possible instance, and sometimes you might have good reason to break a "rule" to accomplish an important design goal. If you feel you must violate one of these conventions, you must document the reason within your code (a good reason for comments!).

Guidelines

1. Communication: code is for humans, so make your code clear, concise, and easy to understand

Project 1

Use meaningful names: give variables, methods, classes, and packages non-abbreviated, intention-revealing names

No magic values: use named constants for all specific values used multiple times or in program logic

Write readable code: use function/variable names and shorten code to organize it (use comments only to explain important design decisions or purpose of code)

Use scope wisely: variables should be declared when they can be assigned, as close as possible to where they are used

Code to expectations: use booleans wisely, for-each loop where possible, use Java API calls instead of implementing yourself

Project 2

"Outline" your code: methods should be implemented "at one level" (try not to mix method calls and low-level if logic in same method)

Read warnings: understand and appropriately fix warnings from Java compiler or IntelliJ (or comment to show you understand why the warning is there and are choosing to leave it as is)

 

2. Modularity: classes represent an abstraction and thus have coherent, closed, and useful interfaces

Project 1

No public instance variables: keep implementation details of your class hidden from the public interface

No static variables: there should be no reason for shared global public state

Project 2

Tell, don't ask: classes should be responsible for their own data and delegate to other objects instead of doing it themselves

Active classes: classes should not consist of only get/set methods and, in general, should minimize their use (get methods should give away the minimal information possible, set methods should validate data received)

Project 3

Superclasses are their own class: thus should not contain instance variables or methods specific to only some subclasses

No "manager" classes: create several classes that work together distributing intelligence, rather than one "smart" class and a few "dumb" helpers

 

3. Flexibility: help users of you code by clearly organizing your classes for extension

   Project 1

   DRY: no duplicated code, either exactly (from cutting and pasting), structurally (in flow of control or decisions), or in setup ("boilerplate" code)

   Single Purpose: keep classes, methods, and variables short and well named by giving them only one purpose

   Project 2

   Use Abstractions: Declare variables types to be as general as possible (i.e., ArrayList should never be publicly visible in your code)

   Polymorphism: use subclassing to avoid "case-based code logic" (i.e., conditional chains or case statements on "type" information)

   Project 3

   Behavior Driven Design: give each class a purpose by focusing on the behavior (or services) it provides first, its state later

   Reduce direct dependence: refer to other classes through interfaces or intermediaries rather than directly when possible