Class Organization

  • Class: a list of variables (public static constants → private static variables → private instance variables)
  • There is seldom a good reason to have a public variable
  • Functions: public function → private utilities (stepdown rule)
  • maintain privacy but in some case protected (accessible for testing)

Classes Should Be Small!

  • The primary rule of designing classes: smaller (with respect to responsibility)
  • The name of a class should describe what responsibilities it fulfills → concise name (bad: Processor or Manager or Super)
  • Brief description of the class in about 25 words without IF, AND, OR, BUT
  • Classes should have one responsibility — one reason to change
  • Many small classes > few large classes
  • High cohesion: Each of the methods of a class should manipulate one or more of those variables
public class Stack {  
private int topOfStack = 0;
List elements = new LinkedList();
public int size() {
// use topOfStack;
}
public void push(int element) {
// use topOfStack, elements
}
public int pop() throws PoppedWhenEmpty {
// use topOfStack, elements
}
  • When classes lose cohesion → split them
  • Ex. PrintPrimes → PrimePrinter, RowColumnPagePrinter, PrimeGenerator

Organizing for Change

  • Open-Closed Principle: Classes should be open for extension but closed for modification
  • When need to “open up” to modifications → check responsibility
  • Concrete classes: contain implementation details
    Abstract classes: represent concepts only
  • Bad: If the lower layer changed → the higher layer should be changed
  • Dependency Inversion Principle: classes should depend upon abstractions, not on concrete details
Previous Design
DIP Design

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Question Kid

An interactive engineer based in Tokyo. CG/Unity/Coding/Book Review