SOLID & object oriented programmeren

SOLID is een afkorting voor de vijf basis patronen van object oriented programeren.

S for Single Responsibility principe.

O for Open - Closed principe.

L for Liskov substitution principe.

I for Interface segregation principe.

D for Dependency inversion principe.

Single Responsibility Principle ( SRP )

A class should have a single responsibility.
A class should have one reason to change.
With a single responsibilty a class should be easier to maintain, to extend and to test.
Code smells for single responsibility are:

  • Class descriptions wich contain AND
  • Method names which doesnt match class name

Open - Closed Principle ( OCP )

A class should be open for extension but closed for modifications. Purpose of this principe is that a extension to your original code should not corrupt all your original code. Your original class should still work as designed.
Or your code must be able to be extended in such a way that if there is a requested change the change can be implemented without the original methods needs to be changed.

Liskov Substitution Principle ( LSP )

It should be possible to change the object to a object which inherits from this object without it's breaking the application.

covariance: the return type of the method in the base class should not be changed in the inherited class.

contravariance: the input type of the method in the base class should not be changed in the inherited class.

preconditions: don't strength the preconditions in the method in the inherited class which overrides the base class methods
in this case a precondition is a check on the input parameters.

postconditions: don't strength the postcondition in the method in the inherited class which overrides the base class method.
in this case a postconditon is a check on the outgoing result.

Overridden methods: don't return new exceptions.

Interface Segregation Principle ( ISP )

A client should not be forced to implement interfaces they don't use.

Dependency Inversion Principle ( DIP )

High level modules should not depend on low level modules. Both should depend on abstractions and those abstractions should not depends on details.
- A high level class should not 'new' the class ( because this is causing the dependency ) but the class should be injected by depency injection.

Dependency inverions is the Principle...to make this work you can use:
- Dependency Injection
- Factory Pattern

{{opmerking.Naam}}:

{{opmerking.OpmerkingText}}

            

Saving your comment....

Naam is verplicht!
Email is verplicht!
Opmerking is verplicht!