Flashcards
Defensive Programming
Cards in this deck (12)
- 1The 3 Rules of Defensive Programming1st : Never Assume Anything (always assert input)
2nd : Use Coding Standard
3rd : Keep it simple - 2Input assertionfor each input:
Do whitelists not blacklist, block everything except valid types
Example:
Numeric: Assign range; signal; zero; Max; Min; Decimal Separator
String: Empty String; min length; max length; weird chars
Object: correctly initialized
All: Is of the correct type; Not null
assert the whitelist
determine fail behaviour
terminate
retry
warning
Check the correct precedence in the set order that statements are resolved - 3Coding StandardsVariable Naming
Indentation
position of brackets
Function Declaration
Don't use magic numbers
Use constant variables - 4Objects instantiationObjects should never be in an inconsistent state. The constructor must initiate the object to a consistent state.
Use immutable objects when you can. - 5High/Strong CohesionHigh cohesion is when you have a class that does a well defined job. Low cohesion is when a class does a lot of jobs that don't have much in common. All the class methods should be related to the class job.
- 6Single Responsibility ('S'olid)A class should have only one concern. As an example, consider a module that compiles and prints a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules.
- 7Low/Loose CouplingComponents in a loosely coupled system can be replaced with alternative implementations that provide the same services.
- 8Keep code simpleFunctions are contracts; Try to use pure function whenever possible
Use database abstraction
Use time tested 3rd party libraries - 9Open/Closed (S'O'LID)1. They are “Open For Extension”.
This means that the behavior of the module can be extended. That we can make
the module behave in new and different ways as the requirements of the applica-
tion change, or to meet the needs of new applications.
2. They are “Closed for Modification”.
The source code of such a module is inviolate. No one is allowed to make source
code changes to it.
Ex: interface shape: method area
class rectangle implements shape : area()
class circle implements shape : area()
Each class has it's own implementation of area so when we do shape.area() will give the correct result no matter if shape is a rectangle or circle - 10Liskov substitution (SO'L'ID)States that we can use a subclass of T where we use T without changing the behavior of the application.
Because a type that extends a base type should not alter the behavior of the base type.
This means that a subclass can override a method of a base class but cannot alter its preconditions (input parameters) and it's postconditions (output / return value type) - 11Interface segregation (SOL'I'D)states that no client should be forced to depend on methods it does not use. It's better to have many small interfaces, than one big interface with many methods.
- 12Dependency inversion (SOLI'D')Basically it states that when passing parameters or creating instances of objects use their interface instead.
Ex: interface shape : area(); print();
class square implements shape...
class circle implements shape...
class shapePrinter print(shape s){s.print()}
shapePrinter depends on the shape interface an not on a particular shape object this means that it can work with any shape
Information
- Description
- Programming (Defensive Programming) Flashcards on Defensive Programming, created by Ricardo Araújo on 17/04/2018.
- Created by
- Ricardo Araújo
- Views
- 1
- Rating