##Ein Beispiel... #Espressomaschine

Bedienelemente (UI)

  • Power On/Off
  • Große Tasse
  • Kleine Tasse
  • Heißwasser
  • Wasserdampf

Anzeigen (UI)

  • Ein / Aus
  • Betriebsbereit
  • Wassertank leer
  • Bohnenbehälter leer
  • Kaffeesatzbehälter voll

Hardware - Komponenten

  • Schalter
  • Display (optional)
  • LEDs
  • Wassertank
  • Kaffeesatzlade
  • Bohnenbehälter
  • Auslass (verstellbar)
  • Tassenwärmer

Hardware - Komponenten

  • Thermoblock
  • Heizung
  • Mahlwerk
  • Vibrationspumpe
  • Satzauswurf

Sensoren

  • Bohnenbehälter Füllstand
  • Wassertank Füllstand
  • Satzbehälter Füllstand
  • Pumpendruck
  • Temperatur
#Let's Draw Something!
#Objektorientiertes Design
##In der Schule... #Objekte der "realen Welt" ##IS-A | Has | Contains

S

O

Liskov Substitution Principle

I

D

#And Now for Something Completely Different
#4 Rules of Simple Design ##By Kent Beck (Paraphrased here)
##Design that is simple... #...passes it's tests
##Design that is simple... #...maximizes clarity
##Design that is simple... #...minimizes duplication
##Design that is simple... #...has fewer elements
#Coupling / Cohesion

cou·ple (verb)

to join (something) to something else

In Software

In software engineering, coupling or dependency is the degree to which each program module relies on each one of the other modules.

co·here

to hold together firmly as parts of the same mass

broadly : stick, adhere

In Software

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.
#SOLID

S

O

Liskov Substitution Principle

I

D

###What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
##Functions that use objects of a base class must be able to use objects of derived classes without knowing it.

Single Responsibility Principle

O

Liskov Substitution Principle

I

D

##There should never be more than one reason for a class to change.

Single Responsibility Principle

Open / Closed Principle

Liskov Substitution Principle

I

D

##Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
							
for(LineItem i : items) {
	switch(i.getType()) {
		//...
	}
}

Single Responsibility Principle

Open / Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

D

##Clients should not be forced to depend upon interfaces they do not use.
							
public interface DatabaseUserChangedListener {
	void userChanged(User user);
}
public interface UserDatabase {
	void registerChangeListener(DatabaseUserChangedListener userEditorController);
}
							
						
							
public class UserEditorControllerImpl implements
             UserEditorController, DatabaseUserChangedListener {
	public UserEditorControllerImpl(UserDatabase userDatabase) {
		userDatabase.registerChangeListener(this);
	}

	@Override
	public void saveUser() {
	}

	@Override
	public void userChanged(final User user) {
	}
}
							
						
							
public class UserEditorControllerImpl
             implements UserEditorController {
	public UserEditorControllerImpl(UserDatabase userDatabase) {
		userDatabase.registerChangeListener(new DatabaseUserChangedListener() {
			@Override
			public void userChanged(final User user) {
				UserEditorControllerImpl2.this.userChanged(user);
			}
		});
	}

	@Override
	public void saveUser() {
	}

	private void userChanged(final User user) {
	}
}
							
						
							
public class UserEditorControllerImpl
             implements UserEditorController {
	public UserEditorControllerImpl(UserDatabase userDatabase) {
		userDatabase.registerChangeListener(this::userChanged);
	}

	@Override
	public void saveUser() {
	}

	private void userChanged(final User user) {
	}
}

Single Responsibility Principle

Open / Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

###High level modules should not depend upon low level modules. Both should depend upon abstractions. ###Abstractions should not depend upon details. Details should depend upon abstractions.
##Zurück zu unserer #Espressomaschine
##Was ist das Verhalten der einzelnen Klassen hier? ##Wo implementieren wir welche Logik?
##Wie macht man eigentlich Espresso? #Ohne Automaten?

Was ist die "High-Level Policy" des Espressomachens?

##Welche High-Level Komponenten gibt es? ##Wie hängen sie zusammen?
#Wie ist der Informationsfluss?
#Let's Draw Something!
#To Recap...