单一职责
收录了 单一职责 频道下的 50 篇内容
软件开发中的单一职责
最近在实践微服务化过程中，对其“单一职责”原则深有体会。 那么只有微服务化才可以单一职责，才可以解耦吗？答案是否定的。
设计模式之禅 01 单一职责原则
单一职责原则，英文名称是Single Responsibility Principle，简称是SRP，定义是应该有且仅有一个原因引起类的变更。
设计模式之禅 - 设计原则
本篇是读《设计模式之禅》一书有感而写，之前对设计模式概念比较模糊，看一些开源库源码设计也只是看到些架势，通过学习后回过头细想，一些背后的设计思想才慢慢浮出水面。
Go 语言中如何通过接口来实现单一职责原则
单一职责原则（Single Responsibility Principle，SRP）是面向对象编程中的一个重要原则，它规定一个类应该只有一个单一的职责，即一个类只负责一项功能。这个原则的目的是使得代码更加易于理解、修改和维护。
微服务架构中的单一职责原则：构建高内聚、低耦合的服务
摘要：单一职责原则（Single Responsibility Principle）是面向对象设计中的重要原则之一，也在微服务架构中扮演着关键角色。本文将深入介绍单一职责原则在微服务架构中的意义和应用，并探讨如何利用该原则构建高内聚、低耦合的微服务。
软件架构设计原则之单一职责原则
单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能导致另一个职责的功能发生故障。这样一来，这个类就存在两个导致类变更的原因
【愚公系列】2022 年 06 月 面向对象设计原则 (一)- 单一职责原则
常用的面向对象设计原则有七个，这七大设计原则都是以可维护性和可复用性为基础的，这些原则并不是孤立存在的，它们相互依赖相互补充，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。
设计模式之美——单一职责（Single Responsibility Principle）
不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成
架构设计原则之我见（二）：SOLID 原则
设计师所设计的目标系统，其职责应该是单一的。
端口和适配器架构——DDD 好帮手
本文介绍用端口和适配器架构概念作为实践领域驱动设计的辅助方法。
SOLID 仍然与现代软件架构相关吗？
SOLID 原则适不适用于微服务？
O’Reilly 软件架构大会第一天内容回顾
本文将对4月12日至13日在纽约举办的O'Reilly软件架构大会第一天的内容进行简单回顾。第一天的演讲内容包括：“blah, blah... microservices...blah, blah”、“the evolution of evolutionary architecture”、 “Death Star Security”、“Twelve Patterns for Hypermedia Architecture”、“Architecture Without an End State”以及“Leading Simplicity”等等。
针对 ASP.NET Core Web API 的先进架构
本文将探讨ASP.NET Core是如何使现代web API的构建变得更加容易的。它使实现易于设计、测试和维护。通过使用端口和适配器模式，业务逻辑可以从API框架和数据访问中分离出来。
iOS 遗留系统重构实践
在过去的几个月内，我主导着团队完成了一项工程浩大（累积八个人月的工作量）的重构工作——为我们的App替换数据库。之所以能够把这种伤筋动骨的事情称之为重构，是因为在这段时间内，我们每天向主干合并两到三次代码，期间App上线五次，用户没有感知到任何影响。在这篇文章中，我将讲述我们如何在不影响系统外部行为，也不影响正常交付的情况下，替换掉了数据库实现。
京公网安备 11010502039052号 | 产品资质
