Rigidity: code is difficult to change. Fragility: tendency to break in many places with small changes.

Immobility: hard
to reuse. Viscosity: slow, inefficient, long compile times. Needless complexity: dont overdesign. Needles repetition:
unify equal things. Opacity: hard to read and understand.
Data structure-oriented vs. Object-oriented classes:
Data structure:
Top down, programs are divided into functions, less secure, no data hiding, less reusability, more function
dependency, less abstraction.
Object-Oriented:
Bottom up, inheritance, encapsulation, abstraction. Program split in objects. More secure, hides data. More reusability,
less function dependency, more abstraction and flexibility.
YAGNI: Ya aint gonna need it.
DRY: Dont repeat yourself.
Tell, dont ask: tell an object what to do, dont ask for data.
Law of Demeter: any method of an object should only call methods belonging to: 1 itself, 2 any parameters that
were passed into the method, 3 any objects it created.
Command-query separation:
Every method should be either a command: performs action or a query: returns data to the caller, but not do both.
Design Patterns Know the names!
Factory methods: a static method of a class that returns an object of that class' type. But unlike a constructor, the
actual object it returns might be an instance of a subclass. Unlike a constructor, an existing object might be reused,
instead of a new object created. Unlike a constructor, factory methods can have different and more descriptive names
Flyweight: The Flyweight pattern describes how to share objects to allow their use at fine granularity without
prohibitive cost. Each "flyweight" object is divided into two pieces: the state-dependent (extrinsic) part, and the state-
independent (intrinsic) part. Intrinsic state is stored (shared) in the Flyweight object. Extrinsic state is stored or
computed by client objects, and passed to the Flyweight when its operations are invoked.
Command: Command decouples the object that invokes the operation from the one that knows how to perform it. To
achieve this separation, the designer creates an abstract base class that maps a receiver (an object) with an action (a
pointer to a member function). The base class contains an execute() method that simply calls the action on the
receiver.
All clients of Command objects treat each object as a "black box" by simply invoking the object's virtual execute()
method whenever the client requires the object's "service". A Command class holds some subset of the following: an
object, a method to be applied to the object, and the arguments to be passed when the method is applied. The
Command's "execute" method then causes the pieces to come together. Sequences of Command objects can be
assembled into composite (or macro) commands.
State: The state pattern is a behavioral software design pattern that implements a state machine in an object-
oriented way. With the state pattern, a state machine is implemented by implementing each individual state as a
derived class of the state pattern interface, and implementing state transitions by invoking methods defined by the
pattern's superclass. The state pattern can be interpreted as a strategy pattern which is able to switch the current
strategy through invocations of methods defined in the pattern's interface. This pattern is used in computer
programming to encapsulate varying behavior for the same object based on its internal state. This can be a cleaner
way for an object to change its behavior at runtime without resorting to large monolithic conditional statements and
thus improve maintainability.
Model-view-presenter: Modelviewpresenter (MVP) is a derivation of the modelviewcontroller (MVC) architectural
pattern, and is used mostly for building user interfaces. In MVP the presenter assumes the functionality of the "middle-
man". In MVP, all presentation logic is pushed to the presenter
UML
Testing
Code coverage: used to describe the degree to which the source code of a program is executed when a particular
test suite runs.
Boundary testing: where test cases are generated using the extremes of the input domain, e.g. maximum,
minimum, just inside/outside boundaries, typical values, and error values. It is similar to Equivalence Partitioning but
focuses on "corner cases".
Equivalence partition testing: software testing technique that divides the input data of a software unit into
partitions of equivalent data from which test cases can be derived. In principle, test cases are designed to cover each
partition at least once.