Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Single Level of Abstraction (SLA)
principles:single_level_of_abstraction

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
principles:single_level_of_abstraction [2014-06-30 23:17] – origin, Further Reading christianprinciples:single_level_of_abstraction [2020-09-09 15:26] – old revision restored (2014-07-01 11:12) 116.202.228.169
Line 12: Line 12:
 ===== Principle Statement ===== ===== Principle Statement =====
  
-Each [[glossary:module]] should be written in terms of a single level of abstraction.+Each method should be written in terms of a single level of abstraction.
  
  
Line 36: Line 36:
  
 ===== Caveats ===== ===== Caveats =====
 +An exception where it may be helpful not to adhere to the principle are certain algorithms. When implementing for instance a sorting algorithm, keeping the algorithm together can be considered more readable than splitting it up into several small functions. This is because certain algorithms are well known and splitting them up may disguise them. A suitable compromise has to be found in such a case.
  
-See section [[#contrary principles]].+See section [[#contrary principles]] for further aspects.
  
  
 ===== Origin ===== ===== Origin =====
  
-Stated in  +Stated in [[resources:Clean Code]] (p. 36). The principle is maybe older, though.
-{{page>resources:Clean Code#reference}} (on page 36). The principles is maybe older.+
  
 ===== Evidence ===== ===== Evidence =====
Line 60: Line 60:
  
 ==== Specializations ==== ==== Specializations ====
 +  * [[One Line Blocks]]
  
 ==== Contrary Principles ==== ==== Contrary Principles ====
- 
   * [[More Is More Complex|MIMC]]: Adhering to SLA results in more methods and classes.   * [[More Is More Complex|MIMC]]: Adhering to SLA results in more methods and classes.
   * [[Principle of Separate Understandability|PSU]]: The purpose of SLA is to avoid [[glossary:mental grouping]]. On the other hand just adhering to SLA and neglecting PSU may result in the opposite: The reader of the code has to do [[glossary:mental inlining]]. Sometimes it can be more readable to allow a small amount of statements on the "wrong" level of abstraction (like having a guarding if statement in a higher level method).   * [[Principle of Separate Understandability|PSU]]: The purpose of SLA is to avoid [[glossary:mental grouping]]. On the other hand just adhering to SLA and neglecting PSU may result in the opposite: The reader of the code has to do [[glossary:mental inlining]]. Sometimes it can be more readable to allow a small amount of statements on the "wrong" level of abstraction (like having a guarding if statement in a higher level method).
Line 77: Line 77:
 ===== Examples ===== ===== Examples =====
  
-==== Example1:  ====+==== Example1: Loops ==== 
 + 
 +A typical example for the application of SLA is a loop iterating over a certain data structure: 
 + 
 +<code java> 
 +public List<ResultDto> buildResult(Set<ResultEntity> resultSet) { 
 +    List<ResultDto> result = new ArrayList<>(); 
 +    for (ResultEntity entity : resultSet) { 
 +        ResultDto dto = new ResultDto(); 
 +        dto.setShoeSize(entity.getShoeSize());         
 +        dto.setNumberOfEarthWorms(entity.getNumberOfEarthWorms()); 
 +        dto.setAge(computeAge(entity.getBirthday())); 
 +        result.add(dto); 
 +    } 
 +    return result; 
 +} 
 +</code> 
 + 
 +There are two levels of abstractions in this method. First there is the loop which acts upon the whole result set and second there is the loop body which converts a single entity to a [[patterns:Data Transfer Object|DTO]]. For the latter there is no syntactical grouping. The reader of the code has to find out that the first four lines of the loop body belong together. The code also doesn't explicitly state that these four lines convert an entity to a DTO. So the following code is better: 
 + 
 +<code java> 
 +public List<ResultDto> buildResult(Set<ResultEntity> resultSet) { 
 +    List<ResultDto> result = new ArrayList<>(); 
 +    for (ResultEntity entity : resultSet) { 
 +        result.add(toDto(entity)); 
 +    } 
 +    return result; 
 +} 
 + 
 +private ResultDto toDto(ResultEntity) { 
 +    ResultDto dto = new ResultDto(); 
 +    dto.setShoeSize(entity.getShoeSize());         
 +    dto.setNumberOfEarthWorms(entity.getNumberOfEarthWorms()); 
 +    dto.setAge(computeAge(entity.getBirthday())); 
 +    return dto; 
 +} 
 +</code> 
 + 
 +Now there are two smaller methods each of which is written in terms of a single level of abstraction. This is better readable as no mental grouping is necessary. Furthermore the two methods are still separately understandable ([[Principle of Separate Understandability|PSU]]) so no mental inlining is necessary and if you don't care about the details of the ''toDto'' method, you can just read and understand ''buildResult'' without being distracted by unnecessary detail. 
 + 
 +==== Example2: Commented Code Blocks ==== 
 + 
 +==== Example3: Algorithms ==== 
  
 ===== Description Status ===== ===== Description Status =====
principles/single_level_of_abstraction.txt · Last modified: 2021-10-18 22:03 by christian