The author: Winston Walker Royce
The famous paper
jueves, 28 de noviembre de 2019
sábado, 23 de noviembre de 2019
Devil´s advocate technique
This is, in a nutshell, the Devil's Advocate technique. The intent isn't to break the software by sneaking in defects, but to explore how effectively the test suite detects bugs. In the current (simplified) example, the effectiveness of the test suite isn't impressive.
source: https://blog.ploeh.dk/2019/10/07/devils-advocate/
source: https://blog.ploeh.dk/2019/10/07/devils-advocate/
jueves, 14 de noviembre de 2019
miércoles, 13 de noviembre de 2019
viernes, 8 de noviembre de 2019
Some notes about Pluralsigth course: Encapsulation and SOLID by Mark Seemann
- CQS for getting code simpler
- More reading then writing code
- Hide information (not public setters)
- Not invalid states
- Fail Fats
- Never return null
- SOLID, for making code more maintainable
rigidity: design difficult to change, easy to break
viscosity: no needed complexity, overkill design (simplicity)
- Developers have a tendency to attempt to solve specific problems with general solutions by Greg Young
- Instead of being general code should be specific. by Greg Young
- Following the SRP, each concrete class is very specific
- Abstraction is the elimination of the irrelevant and the amplification of the essential by Robert C. Martin
- Start with concrete behavior and discover abstractions as commonality emerges by rules of three
- Favor composition over inheritance for example by strategy, decorator, ... patterns.
- Don´t override inherited base class methods (Liskov Substitution Principle)
- Implements all methods of inherited interface, don´t remove features from inherited class throwing NotSupportedException (Liskov Substitution Principle)
- Prefer a tons of small, concrete, trial, simple and granular classes with a low level of abstraction, than a few classes with a lots of code.
- Client should not depend on method that they do not use (Interface segregation principal)
- Small interface with one operation.
- More reading then writing code
- Hide information (not public setters)
- Not invalid states
- Fail Fats
- Never return null
- SOLID, for making code more maintainable
rigidity: design difficult to change, easy to break
viscosity: no needed complexity, overkill design (simplicity)
- Developers have a tendency to attempt to solve specific problems with general solutions by Greg Young
- Instead of being general code should be specific. by Greg Young
- Following the SRP, each concrete class is very specific
- Abstraction is the elimination of the irrelevant and the amplification of the essential by Robert C. Martin
- Start with concrete behavior and discover abstractions as commonality emerges by rules of three
- Favor composition over inheritance for example by strategy, decorator, ... patterns.
- Don´t override inherited base class methods (Liskov Substitution Principle)
- Implements all methods of inherited interface, don´t remove features from inherited class throwing NotSupportedException (Liskov Substitution Principle)
- Prefer a tons of small, concrete, trial, simple and granular classes with a low level of abstraction, than a few classes with a lots of code.
- Client should not depend on method that they do not use (Interface segregation principal)
- Small interface with one operation.
Suscribirse a:
Entradas (Atom)