Series Navigation: |
Foreword: Bricks Are Ready, How to Assemble Them Stably?
In the first three articles, we followed a clear path:
Article 1 pointed out: Architecture is just "technique" — it can manage layering, but not splitting granularity.
Article 2 proposed Lego Architecture: Split infinitely to minimum particles, making reuse visible.
Article 3 proved with practical product detail page: Bricks like Mapper, Assembler, ListItem can indeed split a 3000-line disaster into 15 independent components.
But there's a question hinted at the end of Article 3 — Splitting is only the first step; assembly determines whether this system can run long-term.
Two pages both require "login before operation" — do you plan to copy-paste two sets of if (isLogin) checks? Three types of posters (product, social, store) share the same "render → screenshot → preview → share" workflow, but with completely different UI layouts — do you plan to write three when branches in Activity, each hundreds of lines long?
This is where design patterns come in. They are not another "silver bullet architecture," but the glue between Lego bricks — using minimal, proven connection methods to stably assemble already-split particles together.
The 23 GoF patterns and more evolving patterns each solve different "assembly" problems: Factory is responsible for creating the right bricks, Strategy for switching replaceable behaviors, Adapter for connecting incompatible interfaces, Observer for responding to state changes, Template Method for solidifying invariant processes... Due to space constraints, this article won't cover all of them, but will select two representative cases from the demo project — Observer and Template Method — to illustrate how design patterns generally work in Lego Architecture.
SOCIAL SHARE CARD GENERATOR