标签：封装 name 原则 student 面向对象编程 string 职责

面向对象编程之封装

一、封装的原则

举例说明：类似于电视机，把所有的东西都封装起来，只展示显示屏，封装一般对结构的属性进行封装，使用方法和包的方式进行封装

（摘抄：https://blog.csdn.net/flyfeifei66/article/details/81532261）

1、单一职责原则

最重要的原则，见名知意。单一职责，强调的是职责的分离，一个方法只干一件事情，只因为一个原因做修改。很多代码之所以需要重构，因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。

从微观上讲，单一职责的方法一目了然，职责明确，利于维护。从宏观上讲是设计的要求，单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，职责过多，可能引起它变化的原因就越多，从而极大的损伤其内聚性和耦合度。

这个原则非常好理解，最常见的违反这个原则的例子就是写“大而全”的方法，一个方法搞定各种逻辑，各种flag，各种分支判断，到最后代码看不出主逻辑是什么了。

如果单一职责原则做的好，代码都不会太长，随便翻开Apache的开源软件源码，大部分的方法都没超过100行，当然有些核心类、管理类等，长代码还是有的。

2、最少知道原则

这也是个非常重要的原则。直接借用定义：一个对象应该对其他对象保持最少的了解。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。

函数层次上也要遵循此原则，方法的开口尽可能的小，入参之间不要有依赖，一个极端的例子：一个方法有3个入参，但是第1个和第2个能计算出第3个，就是违反最少知道原则，第三个参数应该在方法体里计算出来。

入参过多很可能会违反最少知道原则，上面的F1，F2，F3的例子，形参个数多达10个。有些很复杂的场景，传递的参数如果真的必须很多的话，考虑用有意义的实体封装，这个封装其实是对入参“归类”，虽然需要的参数还是需要一一“拿到”然后放进实体里，但是归成一类逻辑上可以看成“一个”。很多公司的规范对形参个数都有要求。

二、工厂模式

为了代码的安全性，Go语言的各个字段都都可以封装到model层，但是私有变量外部又需要访问，所以需要使用工厂模式，Go语言的工厂模式类似于C#中的属性和构造函数

package imp
type student struct{     //私有的结构体
	name string          //定义私有字段
	Age  string
}
func (stu *student) GetName()string{
	return stu.name
}                  //属性
//因为student首字母小写，表示私有，通过工厂模式来解决
func Factory(name string,age string)*student{
       return &student{
		   name:name,
		   Age:age,
	   }
}

如果看完文章对自己有帮助，希望大家点赞支持，谢谢

标签：封装,name,原则,student,面向对象编程,string,职责
来源： https://blog.csdn.net/yyq1102394156/article/details/114015346

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。