每日新聞摘要

This article is a continuation (Part 2) of a discussion comparing the Simple Factory and Factory Method design patterns. It refers back to the prior installment in which the author implemented a Simple Factory and highlighted its limitations. Part 2 continues that exploration, signaling that the previous implementation and the identified shortcomings are the basis for further analysis. The short excerpt indicates readers should continue on Medium to read the full discussion. Because only a snippet is provided here, readers are directed to the full Medium article for complete explanations, examples, and any comparisons or alternatives (such as Factory Method) that the author develops in this follow-up. The piece functions as a bridge from implementation and critique toward deeper treatment in the original Medium post.

本文为“Simple Factory vs Factory Method”系列的第二部分，承接上一篇对 Simple Factory 的实现及其局限性的说明。当前摘录表明作者已在上篇实现工厂模式并识别出问题，本篇将基于这些发现继续展开探讨，进而提供更深入的分析与比较，并引导读者至 Medium 原文获取完整示例与详细论述。由于这里只能看到摘要，完整技术细节与作者在后续篇章中的具体对比请参见原文；本篇主要起到从实现与缺陷检视到更深入讨论的过渡作用。

Kotlin promised cleaner, safer Android code, but many production apps still feel bloated and fragile. The article argues that while Kotlin's features can reduce boilerplate and increase expressiveness, gradual misuse, inconsistent conventions, and weak architectural choices allow complexity and fragility to creep back into codebases. Small antipatterns, inappropriate uses of language features, and neglected maintenance practices compound over time, eroding the advantages Kotlin offered. To prevent this slow degradation the piece calls for awareness of common pitfalls and deliberate engineering practices—such as consistent conventions, proper abstractions, careful feature use, and ongoing refactoring—to keep Android projects maintainable and to retain the benefits of adopting Kotlin. The full article on Medium provides concrete examples and recommendations.

Kotlin 为 Android 开发带来了更简洁与更安全的语法，但许多上线应用仍然显得臃肿和脆弱。文章指出，尽管 Kotlin 能减少样板代码并增强表达力，错误或不一致的使用、薄弱的架构决策与缺乏维护会让复杂性与脆弱性逐步回流：小型反模式、功能误用或缺乏重构的习惯会随时间累积，侵蚀 Kotlin 带来的好处。作者呼吁注意常见陷阱，并采用一致的惯例、恰当的抽象、谨慎使用语言特性和持续重构等工程实践，以保持项目可维护性。欲阅读完整示例与建议，请参阅 Medium 原文。

The article "What Are Intent Filters?" opens with a concise analogy — your Android phone is a city and each app is a building — to introduce the concept of intent filters. Intents are the messages Android uses for inter-component and inter-app communication, and intent filters let an app declare the kinds of intents (actions, data types, categories) its components can respond to. By matching an incoming intent to declared filters, the system decides which app component should handle a request. The piece aims to make this matching mechanism approachable by using everyday imagery and encourages readers to continue on Medium for the full explanation and examples.

文章《什么是 Intent 过滤器？》以一句简洁的比喻开头——把 Android 手机想象成城市、每个应用是一栋建筑——来引出 Intent 过滤器的概念。Intent 是 Android 用于组件间与应用间通信的消息，Intent 过滤器使应用在配置或组件中声明其可以响应的意图（例如动作、数据类型或类别），系统通过这些声明来匹配并选择合适的组件处理请求。文章用日常化的意象帮助讀者理解，並引导他们到 Medium 阅读完整内容与示例。

This article examines why the default Text composable in Jetpack Compose falls short for robust Markdown rendering and outlines what it takes to build a better renderer. It highlights architectural concerns for performance—such as parsing, measuring and layout decisions—and calls attention to the “hidden” problems that rich text brings, like nested styling, inline elements, links, images, and interactive behaviors. Rather than prescribing a single implementation, the piece focuses on concepts and trade-offs developers should consider when implementing Markdown in Compose: how to balance rendering fidelity, responsiveness, and maintainability, and which parts of the pipeline most affect performance. The article is a practical exploration of bridging the gap between simple text rendering and full-featured Markdown support within Compose.

本文讨论了为什么 Jetpack Compose 的默认 Text 组件难以胜任完整的 Markdown 渲染，并概述了构建更好渲染器时需要考虑的要点。文章强调影响性能的架构因素，例如解析、测量与布局决策，并指出富文本带来的“隐藏”挑战，包括嵌套样式、行内元素、链接与图片以及交互行为等。作者并非给出单一实现方案，而是聚焦于实用的概念、权衡与最佳实践，帮助开发者在渲染精确性、响应性能与可维护性之间找到合适的平衡。

This article examines subtyping in Kotlin and presents three fundamental rules intended to make inheritance and generic code safer and more flexible. It centers on understanding variance (how types relate when used in generic classes and interfaces) and applying the Liskov Substitution Principle as a guiding correctness criterion. Rather than prescribing a single pattern, the piece aims to provide reasoning that helps developers choose whether to allow type variance, when to prefer composition over inheritance, and how to design APIs that preserve type safety while remaining expressive. Readers should come away with a clearer mental model for when subtyping is appropriate, how variance annotations affect usability and safety, and how LSP informs substitutions of derived types in place of base types.

本文探讨 Kotlin 的子类型（subtyping），提出三条核心法则，旨在让继承与泛型代码更安全且更灵活。文章以变异（variance）为主线，说明泛型类和接口在不同类型关系下的行为，并以里氏替换原则作为判断正确性的参考。重点在于建立开发者的思维模式，帮助判断何时允许类型变异、何时以组合替代继承，以及如何在保持类型安全的前提下设计仍然富有表现力的 API。阅读后可以更清晰理解 subtyping 的适用情形、变异注解对可用性与安全性的影响，以及 LSP 在用派生类型替换基类型时的考虑。