{"id":17010459,"url":"https://github.com/cool-coding/designpatternj","last_synced_at":"2025-03-22T13:16:55.892Z","repository":{"id":101515791,"uuid":"96181640","full_name":"Cool-Coding/DesignPatternJ","owner":"Cool-Coding","description":"设计模式(Java)","archived":false,"fork":false,"pushed_at":"2017-07-20T09:24:34.000Z","size":70,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2025-01-27T12:46:37.461Z","etag":null,"topics":["design-patterns"],"latest_commit_sha":null,"homepage":null,"language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Cool-Coding.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-07-04T06:12:46.000Z","updated_at":"2019-03-11T04:59:09.000Z","dependencies_parsed_at":null,"dependency_job_id":"bfb7234e-48ca-487d-af5a-1888946eca23","html_url":"https://github.com/Cool-Coding/DesignPatternJ","commit_stats":{"total_commits":43,"total_committers":1,"mean_commits":43.0,"dds":0.0,"last_synced_commit":"f3d67053c2c08ce8755088521316e1fa14974c6f"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Cool-Coding%2FDesignPatternJ","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Cool-Coding%2FDesignPatternJ/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Cool-Coding%2FDesignPatternJ/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Cool-Coding%2FDesignPatternJ/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Cool-Coding","download_url":"https://codeload.github.com/Cool-Coding/DesignPatternJ/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244959458,"owners_count":20538629,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["design-patterns"],"created_at":"2024-10-14T06:04:35.562Z","updated_at":"2025-03-22T13:16:55.836Z","avatar_url":"https://github.com/Cool-Coding.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# DesignPatternJ\n设计模式(Java)\n\n## 1.简单工厂模式\n   比如你买了一条鱼，有煎，炸，烤，煮四种方法吃掉它(方法可能不止这四种，但总是**有限而且不变动**的)，这个时候可以使用简单工厂模式。新建一个“吃法”接口，其中有一个“吃法”的方法，煎，炸，烤，煮分别实现了这个方法，再由一个工厂类封这四个吃法类，我们可以选择任何一种吃法类把这条鱼吃掉。   \n   ![简单工厂模式图][1]    \n   \u003e 图片来源:[老聚博客][2]   \n   - **优点：** 使业务逻辑与界面逻辑分离；通过入参的方式来由工厂类决定实例化哪个对象操作类;   \n   - **缺点：** 当操作类变化或增加操作类时，就必须修改工厂类，违反了开放-封闭原则，可以通过反射解决；   \n   - **使用场景:** 业务操作与界面表示分离时使用；\n## 2.策略模式\n   策略模式最常用的场景就是促销活动，乘车方案，角色控制等这样需要经常变换策略的业务。    \n   \u003e 策略模式(Strategy)定义了算法家族，分别封装起来，让他们之前可以相互替换，此模式让算法的改变，不影响使用算法的客户。   \n   ![策略模式图][3]   \n   \u003e 图片来源:[老聚博客][2]   \n   - **优点:** 是方便选择算法(操作方法)；   \n   - **缺点:** 将算法选择权交给客户，可以通过策略+简单工厂+反射来解决这个问题;   \n   - **使用场景:** 对于经常变化操作的业务比较合适\n## 3.抽象工厂模式\n   一个产品有多套操作方案，每一种方案下可以有对该产品的多种操作方法。这个时候需要使用抽象工厂模式，可以随时在多种方案之间切换。   \n   ![抽象工厂设计模式][4]   \n   \u003e 图片来源:大话设计模式-程杰   \n   - **优点:** 可以方便在多个产品实现方案之间切换   \n   - **缺点:** 如果增加操作对象，则修改的范围比较大   \n   - **使用场景:** 产品需要有多种实现方案时\n## 4.装饰模式   \n动态地给一个对象增加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活。   \n![装饰模式][5]    \n\u003e 图片来源:大话设计模式-程杰   \n- **优点:** 不改变对象本身情况下，很容易地对对象进行一些操作，并可以任意决定操作的顺序;每个装饰类只需要关心自己的功能，不需要知道是否有其它装饰类存在以及与它们的关系如何 \n- **缺点:** 可能会产生许多相似的装修功能小类;由客户端决定装饰顺序，可能会不安全。   \n- **使用场景:** 对象首先具有一定的核心功能，其它功能都是随时可以增加或删除时,可以选择使用装饰模式\n\n[1]: http://pic002.cnblogs.com/images/2012/155937/2012070214562479.png \"简单工厂模式图\"\n[2]: http://www.cnblogs.com/wangjq/\n[3]: http://pic002.cnblogs.com/images/2012/155937/2012070310013466.png \"策略模式图\"\n[4]: http://wx3.sinaimg.cn/mw690/9cac8bffly1fha4khgq39j20nn0i0ju5.jpg \"抽象工厂设计模式\"   \n[5]: http://wx1.sinaimg.cn/mw690/9cac8bffly1fhqg8zrhp1j20qq0f9498.jpg  \"装饰模式\"\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcool-coding%2Fdesignpatternj","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcool-coding%2Fdesignpatternj","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcool-coding%2Fdesignpatternj/lists"}