OOP Principles

575 Aufrufe

Veröffentlicht am

OOP Prinzipien Auszug aus der Schulung Clean Code

Single responsibility principle (SRP)
Open closed principle (OCP)
Liskov substitution principle (LSP)
Interface segregation principleI (ISP)
Dependency inversion principle (DIP)

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
575
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
9
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

OOP Principles

  1. 1. SOLID Principles Clean Code: The Solid Principles
  2. 2. Robert C. Martin (Uncle Bob)  Software Craftsman  http://www.cleancoder.com  twitter: @unclebobmartin  OOP seit den 70ern  Unterzeichner "Agiles Manifest"  Books  Clean Code. A Handbook of Agile Software Craftsmanship  The Clean Coder. A Code of Conduct for Professional Programmers
  3. 3. 5 Solid Principles  Der Source Code ist das Design, nicht das Produkt  Die Software ist das Produkt
  4. 4. Single Responsibility Principle
  5. 5. Single Responsibility Principle
  6. 6. Single Responsibility Principle „There should never be more than one reason for a class to change.“ „Es sollte nie mehr als einen Grund dafür geben, eine Klasse zu ändern.“  Robert C. Martin (Uncle Bob): Agile Software Development: Principles, Patterns, and Practices
  7. 7. Open Close Principle
  8. 8. Open Close Principle
  9. 9. Open Close Principle „Modules should be both open (for extension) and closed (for modification).“ „Module sollten sowohl offen (für Erweiterungen), als auch geschlossen (für Modifikationen) sein.“  Bertrand Meyer: Object Oriented Software Construction
  10. 10. Liskovsches Substitutionsprinzip (LSP)
  11. 11. Liskovsches Substitutionsprinzip (LSP)
  12. 12. Liskovsches Substitutionsprinzip (LSP) „Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T“ „Sei q(x) eine Eigenschaft des Objektes x vom Typ T, dann sollte q(y) für alle Objekte y des Typs S gelten, wo S ein Subtyp von T ist.“  Eine Childklasse soll sich so verhalten wie es von der Elternklasse erwartet wird, daher ist eine Objekt Ersetzbarkeit gegeben.  1993 Barbara Liskov und Jeannette Wing
  13. 13. Interface Segregation Principle
  14. 14. Interface Segregation Principle
  15. 15. Interface Segregation Principle – walk() and stand() seperated
  16. 16. Interface Segregation Principle „Clients should not be forced to depend upon interfaces that they do not use.“ „Clients sollten nicht dazu gezwungen werden, von Interfaces abzuhängen, die sie nicht verwenden.“  Robert C. Martin: The Interface Segregation Principle  http://www.objectmentor.com/resources/ar ticles/isp.pdf
  17. 17. Dependency Inversion Principle
  18. 18. Dependency Inversion Principle „A. High-level modules should not depend on low level modules. Both should depend on abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions.“ A. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen. B. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“  Robert C. Martin: The Dependency Inversion Principle. 5/1996
  19. 19. SOLID  Single responsibility principle (SRP)  Open closed principle (OCP)  Liskov substitution principle (LSP)  Interface segregation principleI (ISP)  Dependency inversion principle (DIP)
  20. 20. SOLID  Single responsibility principle (SRP)  Open closed principle (OCP)  Liskov substitution principle (LSP)  Interface segregation principleI (ISP)  Dependency inversion principle (DIP)
  21. 21. SOLID in der Praxis  Wie wende ich SOLID Prinzipien in der Praxis an ?  Welche Hürden und Fallstricke gibt es ?  Was wird oft gegen solche Prinzipien angeführt ?  Wer entscheidet was eine Responsibility ist ?
  22. 22. Lose Kopplung und hohe Kohäsion  Loose Coupling  Nicht zu feste Verknüpfung  High Cohesion  Hohe Spezialisierung  Jede Klasse für genau eine wohldefinierte Aufgabe zuständig
  23. 23. Wie Solid seid ihr?  Erfahrungsberichte der Entwickler  Solid review im Code
  24. 24. Weblinks  Artikel im OOP Buch  http://openbook.galileocomputing.de/oop/oop_kapitel _03_007.htm  Wikipedia Artikel  http://de.wikipedia.org/wiki/Prinzipien_Objektorientie rten_Designs  Java Beispiele  http://java-ccd.blogspot.de/2010/08/rock-solid.html  http://clean-code-developer.de/  http://www.cleancoders.com/

×