Building Maintainable Software-java篇之Couple Architecture Components Loosely



There are two ways of constructing a software design: one way is to make it so simple

that there are obviously no deficiencies, and the other way is to make it so complicated

that there are no obvious deficiencies.

                           —C.A.R. Hoare

Guideline:

• Achieve loose coupling between top-level components.

• Do this by minimizing the relative amount of code within modules that is exposed to (i.e., can receive calls from) mod‐

ules in other components.

• This improves maintainability because independent components ease isolated maintenance.

Motivation

Low Component Dependence Allows for Isolated Maintenance

A low level of dependence means that changes can be made in an isolated manner.

This applies when most of a component’s code volume is either internal or outgoing.

Isolated maintenance means less work, as coding changes do not have effects outside

the functionality that you are modifying.

Low Component Dependence Separates Maintenance Responsibilities

If all components are independent from each other, it is easier to distribute responsi‐

bilities for maintenance among separate teams. This follows from the advantage of

isolated modification. Isolation is in fact a prerequisite for efficient division of devel‐

opment work among team members or among different teams.

By contrast, if components are tightly intertwined with each other, one cannot isolate

and separate maintenance responsibilities among teams, since the effects of modifica‐

tions will spill over to other teams. Aside from that code being hard to test, the effects

of modifications may also be unpredictable. So, dependencies may lead to inconsis‐

tencies, more time spent on communication between developers, and time wasted

waiting for others to complete their modifications.

Low Component Dependence Eases Testing

Code that has a low dependence on other components (modules with mainly internal

and outgoing code) is easier to test. For internal calls, functionality can be traced and

tested within the component. For outgoing calls, you do not need to mock or stub

functionality that is provided by other components (given that functionality in that

other component is finished).

How to Apply the Guideline

The following principles help you apply the guideline of this chapter:

• Limit the size of modules that are the component’s interface.

• Define component interfaces on a high level of abstraction. This limits the types

of requests that cross component borders. That avoids requests that “know too

much” about the implementation details.

• Avoid throughput code, because it has the most serious effect on testing func‐

tionality. In other words, avoid interface modules that put through calls to other

components. If throughput code exists, analyze the concerned modules in order

to solve calls that are put through to other components

Abstract Factory Design Pattern

Component independence reflects the high-level architecture of a software system.

However, this is not a book on software architecture. In this section, we discuss only

one design pattern that we frequently see applied in practice to successfully limit the

amount of interface code exposed by a component: the Abstract Factory design pat‐

tern. A system that is loosely coupled is characterized by relying more on contracts

and less on implementation details.

Many more design patterns and software architecture styles can help in keeping your

architecture components loosely coupled. An example is using a framework for

dependency injection (which allows Inversion of Control). For elaboration on other

patterns, we kindly direct you to the many great books on design patterns and soft‐

ware architecture (see, for example, “Related Books” on page xiv).

The Abstract Factory design pattern hides (or encapsulates) the creation of specific

“products” behind a generic “product factory” interface. In this context, products are

typically entities for which more than one variant exists.

读书笔记:

Building Maintainable Software: Ten Guidelines for Future-Proof Code

by Joost Visser

Copyright © 2016 Software Improvement Group, B.V. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are

also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/

institutional sales department: 800-998-9938 or corporate@oreilly.com.

Acquisitions Editor: Rachel Roumeliotis

Editor: Nan Barber

Production Editor: Matthew Hacker

Copyeditor: Rachel Monaghan

Proofreader: Marta Justak

Indexer: WordCo Indexing Services, Inc.

Interior Designer: David Futato

Cover Designer: Randy Comer

Illustrator: Rebecca Demarest

February 2016: First Edition

Revision History for the First Edition

2016-01-25: First Release

See  http://shop.oreilly.com/product/0636920049159.do

Building Maintainable Software-java篇之Couple Architecture Components Loosely的更多相关文章

  1. Building Maintainable Software-java篇之Separate Concerns in Modules

    Building Maintainable Software-java篇之Separate Concerns in Modules   In a system that is both complex ...

  2. JSON总结(java篇)

    JSON总结(java篇一) JSON简介 JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式.它基于ECMAScript的一个子集. JSON采用完全独立于 ...

  3. [转]有哪些值得关注的技术博客(Java篇)

    有哪些值得关注的技术博客(Java篇)   大部分程序员在自学的道路上不知道走了多少坑,这个视频那个网站搞得自己晕头转向.对我个人来说我平常在学习的过程中喜欢看一些教程式的博客.这些博客的特点: 1. ...

  4. 面试总结——Java篇

    前言:前期对Java基础的相关知识点进行了总结,具体参看:Java基础和面试知识点.近期由于笔者正在换工作(ing),因此下面将笔者在面试过程中或笔者朋友面试过程中反馈的题目进行总结,相信弄清楚下面题 ...

  5. 事件驱动模型实例详解(Java篇)

    或许每个软件从业者都有从学习控制台应用程序到学习可视化编程的转变过程,控制台应用程序的优点在于可以方便的练习某个语言的语法和开发习惯(如.net和java),而可视化编程的学习又可以非常方便开发出各类 ...

  6. Tools:downloading and Building EDK II工具篇:安装/使用EDKII源代码获取/编译工具[2.3]

    Tools:Installing and using the Required Tools for downloading and Building EDK II工具篇:安装/使用EDKII源代码获取 ...

  7. 管中窥豹——框架下的SQL注入 Java篇

    管中窥豹--框架下的SQL注入 Java篇 背景 SQL注入漏洞应该算是很有年代感的漏洞了,但是现在依然活跃在各大漏洞榜单中,究其原因还是数据和代码的问题. SQL 语句在DBMS系统中作为表达式被解 ...

  8. App 组件化/模块化之路——Android 框架组件(Android Architecture Components)使用指南

    面对越来越复杂的 App 需求,Google 官方发布了Android 框架组件库(Android Architecture Components ).为开发者更好的开发 App 提供了非常好的样本. ...

  9. 安卓构架组件——概述 Android Architecture Components

    谷歌官文文档地址:https://developer.android.google.cn/topic/libraries/architecture 安卓构架组建是库的集合:帮助你设计健壮的.易测试的. ...

随机推荐

  1. PAT甲级1016Phone Bills

    #include<iostream> #include<cstdio> #include<cstdlib> #include<vector> #incl ...

  2. C#——工厂模式

    之前我们接介绍了简单工厂,这次我们介绍一种更为常用的模式——工厂模式. 工厂方法模式Factory Method,又称多态性工厂模式.在工厂方法模式中,核心的工厂类不再负责所有的产品的创建,而是将具体 ...

  3. C#调用Win32 api时的内存操作

    一般情况下,C#与Win 32 Api的互操作都表现的很一致:值类型传递结构体,一维.二维指针传递IntPtr.在Win32 分配内存时,可以通过IntPtr以类似移动指针的方式读取内存.通过IntP ...

  4. 【sqli-labs】 less44 POST -Error based -String -Stacked Blind(POST型基于盲注的堆叠字符型注入)

    盲注漏洞,登陆失败和注入失败显示的同一个页面 可以用sleep函数通过延时判断是否闭合引号成功 这个方法有一点不好的地方在于,并不能去控制延时,延时的时间取决于users表中的数据数量和sleep函数 ...

  5. Ubuntu 关闭guest用户

    Ubuntu 关闭guest用户 ca0gu0@ub:~$ cat /etc/lightdm/lightdm.conf [SeatDefaults]autologin-user=falseallow- ...

  6. Linux 之CentOS7使用firewalld打开关闭防火墙与端口

    一.firewalld的基本使用 启动: systemctl start firewalld 关闭: systemctl stop firewalld 查看状态: systemctl status f ...

  7. scss基础

    1.变量$ 全局 局部 .div{ $color:yellow; } 2.类似函数@mixin border-radius($radius) { }引用:@include border-radius( ...

  8. ES6学习历程(变量的解构赋值)

    一.数组的解构赋值 1.举几个例子足以理解 let [a, b, c] = [1, 2, 3]; a:1;  b:2;  c:3; let [x, , y] = [1, 2, 3];  x:1   y ...

  9. 50.percentiles百分比算法以及网站延时统计

    主要知识点 percentiles的用法     现有一个需求:比如有一个网站,记录下了每次请求的访问的耗时,需要统计tp50,tp90,tp99 tp50:50%的请求的耗时最长在多长时间 tp90 ...

  10. emacs 定制进缩风格

    纵览 emacs 文档中描述,进缩风格实现只需要两步:第一步,根据内容与上下文找到对应的进缩风格的类别:第二步,依据进缩风格决定的表达式锚点的进缩偏移.下面我们对 cc-mode 风格定制加以说明. ...