aljaz/hacker-laws
1
1
Fork 0
mirror of https://github.com/dwmkerr/hacker-laws.git synced 2025-12-18 13:14:55 +01:00
Code Issues Packages Projects Releases Wiki Activity

Correct typo reserve/reverse

Browse Source
This commit is contained in:
Dan
2019-01-08 14:00:34 -08:00
committed by GitHub
parent a75f07c53f
commit d646bc5ea0
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -152,7 +152,7 @@ See also:
The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is. The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the xml parser uses that function, but the derived type 'network file' fails when reserve seeking is attempted, then the 'network file' would be violating the principle. As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the xml parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
This principle has particular relevance for object-orientated programming, where type hierarchies must be modelled carefully to avoid confusing users of a system. This principle has particular relevance for object-orientated programming, where type hierarchies must be modelled carefully to avoid confusing users of a system.