If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/youlookwhat/DesignPattern shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Stale and unlicensed — last commit 4y ago

• 3 active contributors
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live youlookwhat/DesignPattern repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/youlookwhat/DesignPattern.

What it runs against: a local clone of youlookwhat/DesignPattern — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in youlookwhat/DesignPattern | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1401 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of youlookwhat/DesignPattern. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/youlookwhat/DesignPattern.git
#   cd DesignPattern
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of youlookwhat/DesignPattern and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "youlookwhat/DesignPattern(\\.git)?\\b" \\
  && ok "origin remote is youlookwhat/DesignPattern" \\
  || miss "origin remote is not youlookwhat/DesignPattern (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "app/src/main/java/com/example/jingbin/designpattern/MainActivity.java" \\
  && ok "app/src/main/java/com/example/jingbin/designpattern/MainActivity.java" \\
  || miss "missing critical file: app/src/main/java/com/example/jingbin/designpattern/MainActivity.java"
test -f "app/src/main/java/com/example/jingbin/designpattern/app/PatternApplication.java" \\
  && ok "app/src/main/java/com/example/jingbin/designpattern/app/PatternApplication.java" \\
  || miss "missing critical file: app/src/main/java/com/example/jingbin/designpattern/app/PatternApplication.java"
test -f "app/src/main/java/com/example/jingbin/designpattern/factory/gcff/XianSimpleRoujiaMoFactory.java" \\
  && ok "app/src/main/java/com/example/jingbin/designpattern/factory/gcff/XianSimpleRoujiaMoFactory.java" \\
  || miss "missing critical file: app/src/main/java/com/example/jingbin/designpattern/factory/gcff/XianSimpleRoujiaMoFactory.java"
test -f "app/src/main/java/com/example/jingbin/designpattern/adapter/V5PowerAdapter.java" \\
  && ok "app/src/main/java/com/example/jingbin/designpattern/adapter/V5PowerAdapter.java" \\
  || miss "missing critical file: app/src/main/java/com/example/jingbin/designpattern/adapter/V5PowerAdapter.java"
test -f "app/src/main/java/com/example/jingbin/designpattern/command/CommandActivity.java" \\
  && ok "app/src/main/java/com/example/jingbin/designpattern/command/CommandActivity.java" \\
  || miss "missing critical file: app/src/main/java/com/example/jingbin/designpattern/command/CommandActivity.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1401 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1371d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/youlookwhat/DesignPattern"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

An Android application demonstrating all 23 Gang of Four design patterns with concrete examples in Java. It provides educational implementations of creational (Singleton, Factory, Builder, Prototype), structural (Adapter, Bridge, Decorator, Facade, Proxy, Flyweight, Composite), and behavioral (Observer, Strategy, Command, Chain of Responsibility, State, Template Method, Iterator, Mediator, Memento, Interpreter, Visitor) patterns with real-world scenarios like mobile phone charging adapters, smart home automation, and vending machines. Standard Android Gradle single-app structure: app/src/main/java contains organized pattern packages (adapter/, bridge/, builder/, chainofresponsibility/, command/, etc.), each with Activity classes for UI demonstration and supporting classes implementing specific pattern roles. MainActivity.java serves as entry point. DataBinding is enabled in build.gradle for modern Android patterns.

Java and Android developers learning design patterns, software engineering students studying OOP principles, and team leads teaching design pattern best practices through runnable code examples on Android devices or emulators.

Moderately mature educational project (version 3.1, versionCode 5 in build.gradle). Contains test instrumentation setup (ExampleInstrumentedTest.java) and organized module structure with clear examples. However, no visible continuous integration configuration, and the README links to external blog posts rather than in-repo documentation suggesting maintenance focus is on demonstration rather than production robustness.

Low risk for educational use. Minimal dependencies (only ByRecyclerView:1.3.2, androidx.recyclerview, androidx.appcompat, JUnit 4.13.2) with stable versions. Single maintainer (youlookwhat) with no evidence of recent activity or breaking changes. Not designed for production use—safe for learning but should not be used as-is in production applications.

No visible active development signals in provided data. The repository appears to be a completed educational reference (version 3.1 released). No open PRs, issues, or recent commit timestamps visible. The project serves as a static documentation resource rather than an actively developed codebase.

Check README for instructions.

Daily commands:

./gradlew assembleDebug
# Or in Android Studio: Build > Build APK(s), then run on emulator/device
adb install -r app/build/outputs/apk/debug/app-debug.apk
adb shell am start -n com.example.jingbin.designpattern/.MainActivity

• app/src/main/java/com/example/jingbin/designpattern/MainActivity.java — Entry point Activity that displays the menu of all 23 design patterns and routes navigation to each pattern's demo Activity.
• app/src/main/java/com/example/jingbin/designpattern/app/PatternApplication.java — Application class that initializes the entire pattern demonstration framework and manages global application lifecycle.
• app/src/main/java/com/example/jingbin/designpattern/factory/gcff/XianSimpleRoujiaMoFactory.java — Core factory pattern implementation demonstrating the Simple Factory approach, used as a reference example throughout the codebase.
• app/src/main/java/com/example/jingbin/designpattern/adapter/V5PowerAdapter.java — Canonical adapter pattern example showing voltage adaptation, fundamental for understanding structural patterns in this repo.
• app/src/main/java/com/example/jingbin/designpattern/command/CommandActivity.java — Demonstrates command pattern with multiple concrete command implementations, essential reference for behavioral patterns.
• app/src/main/java/com/example/jingbin/designpattern/decorator/gem/IEuipDecorator.java — Base decorator interface showing how to extend functionality dynamically, critical for understanding decorator pattern implementation.
• app/build.gradle — Build configuration defining Android SDK versions, dependencies, and databinding support required for all pattern Activities.

Add a New Design Pattern Demo

1. Create a new package under app/src/main/java/com/example/jingbin/designpattern/{patternname} following naming convention (e.g., 'observer' for Observer Pattern) (app/src/main/java/com/example/jingbin/designpattern/{patternname})
2. Create the main Activity class extending AppCompatActivity (e.g., ObserverActivity.java) to demonstrate the pattern with UI components (app/src/main/java/com/example/jingbin/designpattern/{patternname}/{PatternName}Activity.java)
3. Implement the pattern's core classes (interfaces and implementations) in the same package, using business logic examples like 'RoujiaMo' or 'Equipment' for consistency (app/src/main/java/com/example/jingbin/designpattern/{patternname}/*.java)
4. Add a menu entry in MainActivity.java that navigates to your new {PatternName}Activity using Intent routing (app/src/main/java/com/example/jingbin/designpattern/MainActivity.java)
5. Declare the new Activity in AndroidManifest.xml following the existing Activity declaration pattern (app/src/main/AndroidManifest.xml)

Implement a New Structural Decorator

1. Create a new decorator class extending IEuipDecorator in the decorator/gem package (e.g., PurpleGemDecorator.java) (app/src/main/java/com/example/jingbin/designpattern/decorator/gem/PurpleGemDecorator.java)
2. Override getDescription() and getAttack() methods following the pattern established by RedGemDecorator and BlueGemDecorator (app/src/main/java/com/example/jingbin/designpattern/decorator/gem/PurpleGemDecorator.java)
3. Add instantiation and delegation logic in DecoratorActivity.java to demonstrate the new gem decorator in the UI (app/src/main/java/com/example/jingbin/designpattern/decorator/DecoratorActivity.java)

Create a New Factory Implementation

1. Create a new concrete factory class in factory/gcff (Abstract Factory) or factory/jdgc (Factory Method), implementing the factory interface pattern (app/src/main/java/com/example/jingbin/designpattern/factory/gcff/NewRegionRoujiaMoFactory.java)
2. Implement required factory methods that return region-specific RoujiaMo product variants with appropriate Meet and YuanLiao subclasses (app/src/main/java/com/example/jingbin/designpattern/factory/gcff/NewRegionRoujiaMoFactory.java)
3. Register and instantiate the new factory in FactoryActivity.java to demonstrate it alongside existing XianSimpleRoujiaMoFactory implementations (app/src/main/java/com/example/jingbin/designpattern/factory/FactoryActivity.java)

• Android AppCompat Activities — Provides familiar Android UI framework for demonstrating patterns with interactive UI components and lifecycle management
• Java 1.8 / Android SDK 28 — Enables lambda expressions and modern Java syntax for cleaner pattern demonstrations while maintaining broad device compatibility (API 19+)
• Gradle with DataBinding — DataBinding (enabled in build.gradle) allows declarative UI binding, useful for demonstrating observer-like patterns in Android context
• Food/Equipment Domain Models (RoujiaMo, Equipment) — Real-world business logic examples make abstract patterns tangible and easier to understand than generic Object/Item classes

• Educational demos tied to Android Activities vs pure Java classes

  • Why: Makes patterns relevant to Android developers and demonstrates real UI integration
  • Consequence: Harder to run patterns in non-Android environments; adds Activity lifecycle complexity to simple pattern examples

• Chinese domain language (RoujiaMo肉夹馍, YuanLiao原料) in pattern examples

  • Why: Makes patterns memorable and culturally relevant for Chinese developer audience
  • Consequence: Adds cognitive load for

• Signing configuration in build.gradle uses hardcoded passwords ('designpattern' for both storePassword and keyPassword) pointing to ./designpattern keystore file—if building release APK, this file must exist in app/ directory or build will fail.
• DataBinding is enabled but not uniformly used across Activities; some Activities may use traditional findViewById patterns.
• ByRecyclerView:1.3.2 is a custom third-party library (not major Android library); verify its compatibility if updating AndroidX versions.
• minSdkVersion 19 (Android 4.4) is relatively old; some AndroidX libraries may have dropped support, requiring version bump if adding new dependencies.

• Gang of Four (GoF) Design Patterns — This repo comprehensively teaches all 23 canonical design patterns from the seminal 1994 book; understanding these patterns is fundamental to recognizing common solutions in production codebases.
• Adapter Pattern (Object Adapter vs Class Adapter) — The V5PowerAdapter example in this repo demonstrates object composition approach to adapt incompatible interfaces; critical for legacy code integration and hardware abstraction layers.
• Builder Pattern with Director — BuilderActivity shows construction of complex objects step-by-step with Director orchestration; essential for fluent APIs and immutable object creation in Java.
• Chain of Responsibility Pattern — ChainOfResponsibilityActivity demonstrates pass-through request handling (AbstractLogger with ConsoleLogger/FileLogger/ErrorLogger) used in logging frameworks and event handling pipelines.
• Behavioral vs Structural vs Creational Pattern Categories — This repo's organization (creational patterns for object creation, structural for composition, behavioral for object interaction) provides mental framework for choosing appropriate patterns for specific problems.
• Template Method Pattern with inheritance — Used throughout codebase (AbstractLogger extends pattern); defines algorithmic skeleton in parent class allowing subclasses to override steps—core to DRY principle in OOP.
• Strategy Pattern with polymorphism — Enables runtime algorithm selection by encapsulating different strategies in separate classes implementing common interface; critical for testable, flexible code design.

• RefactoringGuru/design-patterns-java — Official comprehensive design patterns guide with Java implementations; serves as canonical reference for same 23 patterns with more detailed walkthroughs
• iluwatar/java-design-patterns — Large-scale educational repository with 100+ design pattern implementations in pure Java with extensive documentation and real-world use cases
• google/android-architecture — Demonstrates Android-specific architectural patterns (MVVM, MVP, MVI) that build on foundational design patterns taught here
• square/okhttp — Production Android library exemplifying Facade, Decorator, and Factory patterns in real HTTP client code; shows patterns applied in practice

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for all 23 design pattern implementations in chainofresponsibility, command, and composite packages

The repo has ExampleInstrumentedTest.java but no actual unit tests for the design pattern implementations. Given this is an educational repo on 23 design patterns, adding JUnit tests for core pattern classes (AbstractLogger, Command implementations, Employee composite structure) would validate the patterns work correctly and serve as executable documentation for learners. Currently only androidTest exists with no real test cases.

• [ ] Create app/src/test/java/com/example/jingbin/designpattern/chainofresponsibility/ChainOfResponsibilityTest.java with tests for AbstractLogger and its implementations (ConsoleLogger, ErrorLogger, FileLogger)
• [ ] Create app/src/test/java/com/example/jingbin/designpattern/command/CommandPatternTest.java with tests for Command interface implementations (LightOnCommand, LightOffCommand, ComputerOnCommand, etc.)
• [ ] Create app/src/test/java/com/example/jingbin/designpattern/composite/CompositePatternTest.java with tests for Employee hierarchy and composite structure
• [ ] Add testImplementation 'mockito' or similar mocking framework to build.gradle if needed
• [ ] Ensure tests verify the core behavior of each pattern (e.g., command execution, chain propagation, composite traversal)

Implement missing structural pattern demos: Facade, Flyweight, and Proxy patterns

The README lists 23 design patterns but the file structure shows incomplete implementations. Looking at the existing code, there are no visible packages/activities for Facade, Flyweight, or Proxy patterns under app/src/main/java/com/example/jingbin/designpattern/. These are critical structural patterns that should have example activities and implementation classes matching the pattern of adapter, bridge, decorator, and composite folders.

• [ ] Create app/src/main/java/com/example/jingbin/designpattern/facade/ with FacadeActivity.java demonstrating complex subsystem simplification
• [ ] Create app/src/main/java/com/example/jingbin/designpattern/flyweight/ with FlyweightActivity.java and FlyweightFactory pattern for resource pooling
• [ ] Create app/src/main/java/com/example/jingbin/designpattern/proxy/ with ProxyActivity.java demonstrating lazy loading or access control proxy
• [ ] Add corresponding entries to MainActivity.java's pattern list to link to these new activities
• [ ] Follow the existing code style and architecture (Activity + supporting model classes) used in other pattern implementations

Add comprehensive JavaDoc comments and code examples to all pattern base classes (Builder, Command, DrawAPI, etc.)

While the repo contains solid implementations of design patterns, there are minimal to no JavaDoc comments explaining the intent, participants, and consequences of each pattern. For an educational resource on 23 design patterns, adding detailed documentation to key abstract classes and interfaces (Builder.java, Command.java, DrawAPI.java, IEquip.java, AbstractLogger.java) would make this an invaluable learning resource. Learners need to understand WHY each pattern exists, not just HOW it's coded.

• [ ] Add JavaDoc to app/src/main/java/com/example/jingbin/designpattern/builder/Builder.java explaining the Builder pattern intent and use cases
• [ ] Add JavaDoc to app/src/main/java/com/example/jingbin/designpattern/command/Command.java with pattern diagram and participant descriptions
• [ ] Add JavaDoc to app/src/main/java/com/example/jingbin/designpattern/bridge/DrawAPI.java explaining the Bridge pattern structure
• [ ] Add JavaDoc to app/src/main/java/com/example/jingbin/designpattern/chainofresponsibility/AbstractLogger.java with chain sequence examples
• [ ] Add JavaDoc to app/src/main/java/com/example/jingbin/

• Add JUnit unit tests for core pattern classes: Create test cases in app/src/test/java/ for pattern implementations (e.g., test V5PowerAdapter conversion logic in AdapterTest.java, test Builder.build() in BuilderTest.java) to establish testing practice.
• Document pattern intent and implementation notes: Add JavaDoc comments and README files to each pattern package (adapter/README.md, builder/README.md) explaining pattern purpose, participants (roles), and when to use, keyed to the concrete examples.
• Implement missing behavioral pattern examples: The file list shows chainofresponsibility and command but gaps for Iterator, Mediator, Memento, Interpreter, and Visitor patterns—add Activity + implementation classes for these 5 patterns to complete all 23.

This Android design pattern educational codebase has several critical and high-severity security issues. The most critical issue is hardcoded credentials in the build configuration visible to anyone with repository access. Additionally, the project uses significantly outdated dependencies (from 2018-2019) which likely contain known vulnerabilities, disabled obfuscation for release builds exposing all code logic, and targets very old Android versions (API 19) that have numerous unpatched security flaws. The combination of exposed credentials, outdated libraries, and weak build configuration creates a high-risk security posture. While this is an educational repository, these practices should never be used in production applications. Immediate remediation includes: externalize all credentials, update all dependencies, enable ProGuard/R8 obfuscation, and increase minimum

• Critical · Hardcoded Credentials in Build Configuration — app/build.gradle (signingConfigs section). The build.gradle file contains hardcoded signing credentials (storePassword, keyPassword, keyAlias) embedded directly in the source code. These credentials are visible to anyone with access to the repository and can be extracted from version control history. Fix: Move credentials to gradle.properties file or use environment variables. Never commit credentials to version control. Use secure credential management systems like GitHub Secrets or encrypted keystores.
• High · Outdated Dependencies with Known Vulnerabilities — app/build.gradle (dependencies section). The project uses outdated dependencies that may contain known security vulnerabilities: androidx.appcompat:1.0.0 (from 2018), junit:4.13.2, and espresso-core:3.1.0. These versions are significantly behind current releases and likely contain patched vulnerabilities. Fix: Update all dependencies to latest stable versions. Regularly use 'gradle dependencies' to check for outdated packages and security advisories. Consider using Dependabot or similar tools for automated dependency updates.
• High · Missing ProGuard/R8 Obfuscation in Release Builds — app/build.gradle (buildTypes.release section). Release builds have minifyEnabled set to false, meaning compiled bytecode is not obfuscated. This makes reverse engineering of the application trivial and exposes design patterns and business logic. Fix: Enable minifyEnabled = true for release builds and configure appropriate ProGuard rules to obfuscate code, remove unused code, and strip sensitive information.
• Medium · Weak Signing Credentials Pattern — app/build.gradle (signingConfigs section). The signing configuration uses the same credentials for both debug and release builds, and uses a generic keystore file name './designpattern' with obvious password 'designpattern'. This weakens release build security. Fix: Use separate, strong credentials for debug and release builds. Keep release keystore securely stored outside the repository with strong, unique passwords.
• Medium · Outdated compileSdkVersion and buildToolsVersion — app/build.gradle (android section). The project targets compileSdkVersion 28 (Android 9, released 2018) and buildToolsVersion 28.0.3. Using outdated SDK versions means missing security patches and modern security features introduced in newer Android versions. Fix: Update compileSdkVersion to 34+ (latest), buildToolsVersion to 34+, and targetSdkVersion to match. Test thoroughly for compatibility with newer Android versions.
• Medium · Low minSdkVersion Allows Vulnerable Android Versions — app/build.gradle (defaultConfig section). minSdkVersion 19 targets Android 4.4 (released 2013) which has numerous known security vulnerabilities and lacks modern security APIs. Supporting such old versions increases attack surface. Fix: Increase minSdkVersion to at least 24 (Android 7.0+) to drop support for versions with critical vulnerabilities. Modern Android versions provide better security APIs and hardening.
• Low · Unencrypted Keystore File in Repository — app/build.gradle and .gitignore. The keystore file './designpattern' is referenced in the build configuration. If it exists in the repository, it should never be committed as it contains signing keys. Fix: Ensure the keystore file is in .gitignore. Never commit keystore files to version control. Use secure CI/CD secret management for release builds.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.