This is my list of all the posts related to the technical practices that I consider the "MicroObjects Technical Pactices".
These are also helpful to me to see what topics I might want to write a little more on. :)

List last updated: 2023-05-14

Driving principle

Have a representation for every concept that exist in the code.

Part 1 - Part 2 - Part 3 - Part 4

• No Getters (or Setters)

  • Awaiting Objects
  • Refactor Legacy Code: Reduce Databags
  • The UI - It Does Nothing
  • Technical Practices: Never Return Your Data
  • MicroObjects: Encapsulation
  • Object Oriented Encapsulation

• Be Immutable

  • MicroObjects: Immutability

• Interface for Behavior Contracts

  • My Thoughts: Interface isn't harmful
  • MicroObjects: Never see the concrete
  • Refactor to Clean Architecture
  • Interface Overloading

• Abstract 3rd Party Code

  • Abstract the OS
  • MicroObjects: UI Example
  • Quick: BookEnd for HttpClient
  • Quick: MicroObjects and Json
  • MicroObjects: Unit Testable UI Interactions
  • MicroObjects: Where our code meets the user
  • MicroObjects: Where our code meets their code
  • MicroObjects: Where our code meets the Operating System
  • HackerNews Android - Let's not crash
  • Testing Android Alert Dialog
  • TDD against Android UI Elements

• No Public Statics

  • MicroObjects: Never see the concrete
  • Technical practices: No Public Statics

• if only as a Guard Clause

  • Technical Practices: if only as a guard clause

• switch and else Always Evil

  • Technical Practices : switch and else always evil

• No nulls

  • NullObject - A Super Power
  • Technical Practices: Trust Your Code
  • Patterns: Null Object
  • MicroObjects: No Nulls

• No new inline

  • AntiPattern: Factory Pattern
  • Libraries are your (not) problem
  • Builders as an antipattern
  • Technical Practices: No new inline
  • MicroObjects: When to instantiate

• Extract Cohesion

  • Refactor Legacy Code: Pass the bigger thing
  • Technical Practices: Low Coupling
  • Technical Practices: High Cohesion
  • DI Frameworks - Tool Impact on Developer Discipline
  • Language Features - Tool Impact on Developer Discipline
  • MicroObjects: Class Creation Dilemma

• Composition, Not Inheritance

  • So Primitive
  • Collections are Primitives
  • ToSystem - My Primitive Protection
  • Encapsulate what can vary
  • A dislike of inheritance - reused
  • Sealed or Abstract
  • A dislike of inheritance
  • Technical Practices: No Inheritance
  • MicroObjects: Class Creation Dilemma
  • MicroObjects: Composition over Inheritance
  • My Thoughts: Double Constructor for Dependency Injection

• No Primitive Obsession

  • Technical Practice: Objects avoid Primitive Obsession
  • Technical Practices: No Primitives
  • Fluent Types

• No Enums

  • Technical Practices: No Enums

• No Logic In Constructors

  • MicroObjects: Code Free Constructors

• Never Reflection

• Never Type Inspection

• Testing

  • TDD - It's not just for testing
  • What I do for DI...
  • Why I hate DI...
  • Toll Impact on Developer Discipline - Dependency Injection Frameworks
  • Toll Impact on Developer Discipline - Frameworks
  • Thoughts - Testing without Mocks
  • Refacotring Legacy Code: Leave Tested Methods Public
  • PowerMock - Tool Impact on Developer Discipline
  • Testability of MicroObjects
  • MicroObjects: Code Free Constructors
  • My Thoughts: Unit Tests
  • My Thoughts: Slow Tests are Bad Tests
  • My Thoughts: Testing on Android
  • Testing Android Alert Dialog
  • TDD against Android UI Elements