Principles

A very good boss of mine introduced me to most of these principles and concepts, which I’ve found very handy and decided to compile a list of such with concise description of each and corresponding links to wiki/other websites that have further explanation. This list will be continuously be updated as I explore more in software engineering!

• You aren’t gonna need it (YAGNI)

  • Functionality should not be added until deemed necessary
    

• Keep It Simple Stupid (KISS)

• Don’t Repeat Yourself (DRY)

  • opposite to WET solutions, “write everything twice”, “we enjoy typing” or “waste everyone’s time”

• Solid (for object oriented programming)

  • Single responsibility
    • Every module/class/function has responsibility over a single part of the functionality
  • Open–closed
    • Open for extension, but closed for modification
  • Liskov substitution
    • Relationship of types and subtypes: an object of type may be substituted with any object of a subtype (of type) without altering any of the desirable properties of the program
  • Interface segregation
    • No client should be forced to depend on methods it does not use
    • “Many client-specific interfaces are better than one general-purpose interface.”
  • Dependency inversion
    • High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).
    • Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
      

• Inversion of Control

  • Framework calls into the custom, or task-specific, code (compared to traditional programming, where the custom code that expresses the purpose of the program calls)
  • Increases modularity of the program and make it extensible
    

• Dependency Injection (DI) vs Service Locator

  • DI: Dependencies are given (without knowing/caring where they come from), therefore much easier to unit test (passing mock implementations)?
  • Service Locator: Dependency provided by service locator
    

• High/Low level modules

  • High level module: Interface / abstraction to be consumed directly
  • Low level module(s): Subsystems for achieving high level functionalities
    

• Multiprocessing vs multithreading

  • Multiprocessing = multiple CPU
    • Can execute multiple processes simultaneously
    • Consumes time/resources to create process
    • Can be symmetric/asymetric classified
  • Multithreading = multiple threads
    • Can execute multiple threads of a process simultaneously.
    • Economical as threads belonging to same process
    • Not classified (neither symmetric/asymetric)
      

• Repository Pattern

  • One repository per entity or business object (~ S in SOLID)
  • Allows code to use objects without having to know how the objects are persisted (everything to run repo is safely contained in repository)
    

• Strategy Pattern (or policy pattern)

  • Software design pattern that enables selecting (family of) algorithms at runtime, instead of running only one single algorithm
  • Allows overall algorithm to vary independently from client to client
  • Included in an influential book Design Patterns by Gamma et al.
    

• Test Fixtures

  • System for the testing with all the necessary code to initialize it
  • e.g. Loading up a database with known parameters from a customer site before running test.

  • Ways to set up:

    • In-line
      • Creates test fixture in the same method as the rest of the test
    • Delegate
      • Places test fixture in separate standalone helper method (accessible by multiple tests)
    • Implicit
      • Places test fixture in setup method which is used to set up multiple test methods
      • Differs from delegate setup: overall setup of multiple tests is in a single setup method
        

  • Pros/Cons

    • Tests are repeatable and preconfigured (same setup)
    • Ease test code design
    • Duplication of test fixtures if using in-line setup

• CAP theorem

  • Impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees:
    • Consistency: Every read receives the most recent write or an error
    • Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write
    • Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
      

• Continuous Integration (CI) / Continuous Development (CD)

  • CI: Practice of continuous merging of developers’ working copies to a shared mainline
    • Each merge should pass all unit tests during a complete build and run (usually automated)
    • Integration tests are usually run automatically on a CI server when it detects a new commit
  • CD: Software functionalities are delivered frequently through automated deployments
    

• Simple Object Access Protocol (SOAP)

  • Messaging protocol specification for exchanging structured information in the implementation of web services
  • Provides extensibility, neutrality and independence
  • Uses XML Information Set, relies on application layer protocols (e.g. HTTP or SMTP)
  • Allows clients to invoke web services and receive responses independent of language and platforms.

• User Datagram Protocol (UDP) and Transmission Control Protocol (TCP)

  • UDP (lower overhead)
    • Provides a connectionless datagram service that emphasizes reduced latency over reliability
    • Simple, minimum of protocol mechanisms
    • Provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram
    • No guarantee of delivery, ordering, or duplicate protection
  • TCP (guaranteed delivery)
    • Reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network
    • Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP. Applications that do not require reliable data stream service may use the User Datagram Protocol (UDP)
      

• Representational State Transfer (REST)

  • A software architectural style for Web services.
  • Such Web services provide interoperability between computer systems on the Internet
  • Allow requesting systems to access and manipulate textual representations of Web resources by through uniform and predefined set of stateless operations
  • Requests made to resource URI will elicit a response with a payload formatted in HTML, XML, JSON, or some other format.
  • Fast performance, reliability, and able to grow by reusing components that can be managed and updated without affecting the system as a whole, even while it is running.
  • HTTP (most common) operations are GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS and TRACE
    • GET: requests a representation of the specified resource
    • HEAD: asks for a GET response but without the body (e.g. meta-info)
    • POST: requests server to accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. Not idempotent as same multiple requests leads to multiple URIs created on server.
    • PUT: requests that the enclosed entity be stored under the supplied URI. Modifies if exists, creates if not. Idempotent as requests of the same thing multiple times are equivalent to a single request
    • DELETE: deletes the specified resource.
    • TRACE: echoes received request so that a client can see what (if any) changes or additions have been made by intermediate servers.
    • OPTIONS: returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource.
    • CONNECT: converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy
    • PATCH: applies partial modifications to a resource