COMP1531
5.3 - SDLC Design - Software Engineering Principles
Design Smells
- Rigidity: Tendency to be too difficult to change
- Fragility: Tendency for software to break when single change is made
- Immobility: Previous work is hard to reuse or move
- Viscosity: Changes feel very slow to implement
- Opacity: Difficult to understand
- Needless complexity: Things done more complex than they should be
- Needless repetition: Lack of unified structures
- Coupling: Interdependence between components
Design Principles
Purpose is to make items:
- Extensible
- Reusable
- Maintainable
- Understandable
- Testable
Often, this is achieved through abstraction. Abstraction is the process of removing characteristics of something to reduce it some a more high level concept
DRY
"Don't repeat yourself" (DRY) is about reducing repetition in code. The same code/configuration should ideally not be written in multiple places.
Defined as:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"
DRY
How can we clean this up?
import sys
if len(sys.argv) != 2:
sys.exit(1)
num = int(sys.argv[1])
if num == 2:
for i in range(10, 20):
result = i ** 2
print(f"{i} ** 2 = {result}")
elif num == 3:
for i in range(10, 20):
result = i ** 3
print(f"{i} ** 3 = {result}")
else:
sys.exit(1)
DRY
How can we improve this?
import jwt
encoded_jwt = jwt.encode({'some': 'payload'}, 'applepineappleorange', algorithm='HS256')
print(jwt.decode(encoded_jwt, 'applepineappleorange', algorithms=['HS256']))KISS
"Keep it Simple, Stupid" (KISS) principles state that a software system works best when things are kept simple. It is the believe that complexity and errors are correlated.
Your aim should often be to use the simplest tools to solve a problem in the simplest way.
KISS
Example 1: Write a python function to generate a random string with up to 50 characters that consist of lowercase and uppercase characters
KISS
Example 2: Write a function that prints what day of the week it is today
KISS
Example 3: Handling command line arguments
python3 commit.py -m "Message"
python3 commit.py -am "All messages"Encapsulation
Encapsulation: Maintaining type abstraction by restricting direct access to internal representation of types (types include classes)
Example:
Consider this code:
What if we wanted to store points in polar coordinates?
class Point:
def __init__(self, x,y):
self.x = x
self.y = y
def distance(start, end):
return sqrt((end.x - start.x)**2 + (end.y - start.y)**2)Encapsulation
Encapsulation
Example:
Consider this code:
Can we prevent stealing spots in the queue?
class Queue:
def __init__(self):
self.entries = []
def enqueue(self, entry):
self.entries.append(entry)
def dequeue(self):
return self.entries.pop(0)
Top-down thinking
Similar to "You aren't gonna need it" (YAGNI) that says a programmer should not add functionality until it is needed.
Top-down thinking says that when building capabilities, we should work from high levels of abstraction down to lower levels of abstraction.
Top-down thinking
Question 1: Given two Latitude/Longitude coordinates, find out what time I would arrive at my destination if I left now. Assume I travel at the local country's highway speed
Why is well designed software important?
- When you only do this loop once, writing bad code has minimal impacts
- When we complete this "cycle" many times, modifying bad code comes at a high cost
Why is well designed software important?
"Poor software quality costs more than $500 billion per year worldwide" – Casper Jones
Systems Sciences Institute at IBM found that it costs four- to five-times as much to fix a software bug after release, rather than during the design process
Why do we write bad code?
Often, our default tendency is to write bad code. Why?
-
It's quicker not to think too much about things
- Good code requires thinking not just about now, but also the future
- Pressure from business we're looking for
- Refactoring takes time
Bad code: Easy short term, hard long term
Good code: Hard short term, easy long term
Why do we want to write good code?
-
More consistent with Agile Manifesto
- "Welcome changing requirements"
- Adapt easier to the natural SD life cycle
Refactoring
Restructuring existing code without changing its external behaviour.
Typically this is to fix code or design smells and thus make code more maintainable
Finding a balance
- Don't over-optimise to remove design smells
- Don't apply principles when there are no design smells - unconditional conforming to a principle is a bad idea, and can sometimes add complexity back in
COMP1531 21T1 - 5.3 - SDLC Design - SE Principles
By haydensmith
