03-24

Software design

• Useful cuz code may not just be yours / other people are reading it!

The central idea of software engineering is modularization

• small chunks that do 1 thing, and are combined into a big thing we want!

What makes good software:

• Modularity
  • The ability to reduce duplicate code
  • Enabling reuse
• Correctness
  • To write “bug free” code, you gotta test
  • The best we can do is say “we have no issues at the moment”, so at that point the program is “bug-free”
• Maintainability
  • Easy to understand
  • Clearly/cleanly written
  • Well-documented
• Efficiency
  • The complexity should be good
  • it should be well-implemented depending on your language

• Privacy

• Reusable
  • Abstraction
• Extendable
  • extendable = if behaviour isn’t added, it should be easy to add
• Openness
  • FOSS ⇒ Easy to edit, hard to hide evilness
  • Proprietary ⇒ Easy to hide evilness

Modules

Each module in C has these things:

1. One header file (.h)
   1. Contains function declarations (but not their implementations)
      1. i.e. int BFS_find_path(float Adj[][], int i, int j, int visited[]); is a function declaration
   2. Contains constants
   3. The compile needs these from headers like stdio.h so that it knows the functions “exist” and will do something about it.
2. One/more implementation files (.c)
   1. These implement what is given by the header file.
   2. All of these combined should implement every function used by the application

todo when using headers, does the compiler somehow know the .c exists too? Or is that part of the linking? uhhh idrk.

An example

We are making a program with

1. Module for DFS
   1. DFSgraphs.h
   2. DFSgraphs.c
      1. This will have #include "DFSgraphs.h"
2. PacMan
   1. Pacman.h
   2. Pacman.c
      1. Compiling Pacman.h and Pacman.c together gets you a Pacman.o, but this “object file” cannot run by itself (even if it has a main(), it will never be called by itself)

Linking the files (Pacman.o, DFSgraphs.o, and maybe main_game.c (which may contain the actual main()) via a makefile) will get you your Pacman.exe

More specific

To build it, you do these steps:

1. Compile each module (the .h and .c combined) into an object file .o
   • Contains executable code for functions of DFSgraphs
     • ”has placeholders for functions from other modulestodo”
   • You cannot run the .o cuz there is no process to run it, and there is no main()
   • Even when you compile pacman.o we cannot run it even if it has a main function
2. Link the object files to make pacman.exe
   • It goes into pacman.o, sees what functions it needs from FPSgraph.h, grabs the implementations from DFSgraphs.c, and use that
   • The linking process is what replaces the placeholder implementation with the real deal