社区
C++ 语言
帖子详情
关于只有一个对象的类和不能被继承的类
xusea
2003-10-17 10:11:56
请教大家两个问题:
1.建立一个类,只能有一个对象。
2.建立一个类,不能被继承,最好能和普通的类差不多,我会建立一个类,但是用的指针指向类来建立成对象了。把构造函数放到私有中去,能不能通过公有函数来调用构造函数
建立对象呢?
...全文
159
24
打赏
收藏
关于只有一个对象的类和不能被继承的类
请教大家两个问题: 1.建立一个类,只能有一个对象。 2.建立一个类,不能被继承,最好能和普通的类差不多,我会建立一个类,但是用的指针指向类来建立成对象了。把构造函数放到私有中去,能不能通过公有函数来调用构造函数 建立对象呢?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
24 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
xusea
2003-10-22
打赏
举报
回复
学习
magicblue
2003-10-20
打赏
举报
回复
我认为不可能。因为C++不是Java,即便可以模仿出final,但终究还是模仿。
panzhaoping
2003-10-20
打赏
举报
回复
好
alongfly
2003-10-20
打赏
举报
回复
学习
xusea
2003-10-20
打赏
举报
回复
关注
fengfeng2003
2003-10-19
打赏
举报
回复
关注
xueweizhong
2003-10-19
打赏
举报
回复
问一下这里的高手,有没有方法实现
final member : 不能被override或者hide?
如果没有这种可能性,请说明理由?
xusea
2003-10-19
打赏
举报
回复
还能再详细讨论么?
oo
2003-10-18
打赏
举报
回复
学习
jhyu
2003-10-18
打赏
举报
回复
小飞侠,我找的那篇文章里面特别说明了,是提供你所说的这种方案之外的另一种方案
magicblue
2003-10-18
打赏
举报
回复
有这么麻烦吗
class UnDerivable
{
public:
UnDerivable* create()
{
p = new UnDerivable;
return p;
}
~UnDerivable()
{
delete p;
}
private:
UnDerivable* p;
UnDerivable(){/*......*/}
};
Wolf0403
2003-10-18
打赏
举报
回复
晕,说错了。
但是总感觉这个 UnDerivable 类颇有点奇怪。它没法在栈上构造对象,而且如果把 create 不改成 static 则也没法使用。
xusea
2003-10-18
打赏
举报
回复
是应该在C++中讨论
magicblue
2003-10-18
打赏
举报
回复
UnDerivable 的意思是 un-(前置,表否定)+ derive(继承)+ able(后置,表形容词)。本来就不是singleton。
没有friend,你的NonDeriveClass根本就是非法的。
singleton的写法一般来说是这样的:
class singleton
{
public:
static singleton* create()
{
if(p == 0)
p = new singleton;
return p;
}
private:
static singleton* p;
singleton();
singleton(const singleton&);
};
singleton* singleton::p = 0;
Wolf0403
2003-10-18
打赏
举报
回复
另外:
1、如果说 NonDeriveHelper 不能继承,那么我的 NonDeriveClass 从哪里来的?
2、你的 UnDerivable::create() 每次返回一个指向不同的堆上对象的指针,根本不是 Singleton
Wolf0403
2003-10-18
打赏
举报
回复
magicblue(小飞侠)
代码随手写的,有错误,望见谅。
但是,你写的这个代码,无法使用。或许是我没有理解透,还望给出示例代码,谢谢。
我的第二个代码忘记了一个 friend 声明,其它的没错。
jhyu(阎罗大王把小不死炸死了) 的文章里已经有很详细的代码和说明,不重复。
至于 Singleton,我看过的实现方法,一个是保存一个对象,一个是把所有方法都设为静态方法。如果你有好的实现方法,不妨贴出来。
xusea
2003-10-18
打赏
举报
回复
请再讨论
多谢
学习中
magicblue
2003-10-18
打赏
举报
回复
确实是,没注意UnDerivable的create无法被调用,如果加上friend class helper;似乎又回到老路上了。下面是一个可用的UnDerivable,好处是不必承担父类的vptr,对象模型和普通对象一样;坏处是必须在构造时在构造参数的最后加个0
class UnDerivable
{
public:
~UnDerivable(){}
template<class T> UnDerivable(T para){/* the same as UnDerivable() */}
private:
UnDerivable(){/*......*/}
};
main()
{
UnDerivable obj(0);
}
magicblue
2003-10-17
打赏
举报
回复
Wolf0403
这个Singleton 不能被继承,不能有虚函数,不能控制他的初始化和清理
NonDeriveClass 有什么用?NonDeriveHelper 已经就是一个不能被继承的类了吧
jhyu
2003-10-17
打赏
举报
回复
第二个我找到了方法,具体在下面的文章,大家一起学习
如何使类不能被继承
2003-4-11 12:52:02 DPG 阅读次数: 1362
如果大家熟悉java的话应该知道java中有一种类不能被继承,那就是final类.这种类有很多用处,尤其是在大的项目中控制类的继承层次. 使子类数量不至于爆炸.在使用了多继承的类层次中这也是防止出现菱形继承层次结构的一个好办法. 要实现一个不能被继承的类有很多方法.
如何使类不能被继承呢?主要的思路就是使子类不能构造父类的部分,这样子类就没有办法实例化整个子类.这样就限制了子类的继承. 所以我们可以将父类的构造函数声明成为私有的,但是这样父类不就不能实例化了吗?可以添加一个静态帮助函数来进行构造. 虽然这样很简陋.但是这的确是一种解决方法.
可是如果只有这个方法能够解决,那么C++实在是太不灵活了.而且这也不值得写一片文章出来!有没有办法解决上面的方法中的那些问题呢?
当然有!我们可以利用友员不能被继承的特性!
首先假设已经有一个类CXX.这是某一个类层次的分支,我们现在要从CXX继承一个Final子类CParent来,也就是CParent不能够被继承. 我们可以充分利用友员不能被继承的特点,也就是说让CParent是某一个类的友员和子类,CParent可以构造,但是CParent的子类CChild确不能继承那个友员特性,所以不能被构造.所以我们引入一个CFinalClassMixin.
我们对这个类的功能是这么期望的:
任何类从它继承都不能被实例化
同时这个类本身我们也不希望它被实例化.
如何实现这个类那?很简单!那就是实现一个构造函数和析构函数都是private的类就行了.同时在这类里面将我们的CParent声明为友员. 代码如下:
class CFinalClassMixin
{
friend class CParent;
private:
CFinalClassMixin(){}
~CFinalClassMixin(){}
};
>//我们的CParent代码应该如下:
class CParent:publicCXXX
{
public:
CParent(){}
~CParent(){}
};
它是从CXXX扩展的一个类(注,此时它还是能够被继承).现在我们需要它不能被继承.那么只要将代码改成
class CParent:public CFinalClassMixin, public CXXX
{
public:
CParent(){}
~>CParent(){}
};
就行了.现在从CParent继承一个子类试试
class CChild:public CParent{};
编译一下代码试试,发现:竟然没有作用!!
靠,这是为什么!
现在再回想一下我们这么操作的原因,也就是这个方案的原理,那就是让父类可以访问Mixin类的构造函数,但是子类不能访问.
现在看看我们的代码,发现父类是CFinalClassMixin类的友员,可以访问它的构造函数.因为友员不能继承,所以CChild不能访问CFinalClassMixin的构造函数.所以应该不能被实例化.
CChild的确不能访问CFinalClassMixin的构造函数,但是它却不必调用它!我想这就是问题的原因所在.CChild是通过CParent来构造CFinalClassMixin的,所以这个友员对他并没有什么用处!
现在问题找到了.要解决很简单.只要让CChild必须调用CFinalClassMixin的构造函数就行了,怎么才能达到目的呢?
还记得虚继承吗?虚继承的一个特征就是虚基类的构造函数由最终子类负责构造!所以将CParent从CFinalClassMixin继承改成从CFinalClassMixin虚继承就可以了.代码如下:
class CParent:virtual public CFinalClassMixin, public CXXX
{
public:
CParent(){}
CParent(){}
};
现在试试,行了.
但是可能有些人会对多继承心有余悸!但是我们这里并没有必要这么担心!为什么?因为我们的CFinalClassMixin类是纯的!pure! 也就是说它根本没有成员变量!那么我们就根本不用担心多继承带来的最大问题.菱形继承产生的数据冗余.以及二义性.
现在还有个不足!那就是我们不能每次使用这个CFinalClassMixin类就在里面加上对某个类的友员声明啊!这多麻烦啊! 虽然不是什么大问题,但是我觉的还是要解决,因为我充分信任C++!
解决的方法也很简单!那就是使用模板!具体描述就省略了,给出代码大家一看就知道了
下面是我得测试程序的完整代码(其中的CFinalClassmixin已经改成模板)
// finaltest.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include
using namespace std;
template
class CFinalClassMixin
{
friend T;
private:
CFinalClassMixin(){}
~CFinalClassMixin(){}
};
class CXXX
{
public:
CXXX(){cout << "I am CXXX" << endl;}
~CXXX(){}
};
class CParent:virtual public CFinalClassMixin, public CXXX
{
public:
CParent(){}
~CParent(){}
};
class CChild:public CParent{};
int main(int argc, char* argv[])
{
CParent a; // 可以构造
//CChild b; //不能构造
return 0;
}
现在只要对不想被继承的类加入一个CFinalClassMixin混合类做父类就行了.
通过限制构造函数,我们就达到了限制继承的目的.但是这对有些还是个例外,比如全是静态函数的类.这些类本身就不需要构造. 所以我们对它没有办法.但是在大多数情况下,一个全是静态函数的类多少暗示了程序本身的设计可能是需要斟酌的.
其实这只是Mixin类(混合类)使用的一个小小例子.还有很多其他的用处,比如UnCopiale等等.就不多说了. 我想说明的是大家可能对多继承比较反感.但是过分否定也是得不偿失的.现在对多继承到底应不应该使用还处在争论阶段. 我觉得一个方法是否使用得当,关键还是在于使用的人
加载更多回复(4)
区块链之Go语言设计模式
面试的时候,设计模式会经常被问到。其实我们在写代码中或多或少会用到一些模式,面试官问你设计模式的问题,更多是看你有没有总结过。如果一直都是在那垒代码,你当然会认为这是个很难的问题。所以我们需要总结一下设计模式。 1. SINGLETON 单例模式 单例模式:单例模式确保某
一个
类
只有
一个
实例,而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 俺有6个漂亮的老婆,她们的老公都是我,我就是我们家里的老公Sigleton,她们只要说道“老公”,都是指的同
一个
人,那就是我(刚才做了个梦啦,哪有这么好的事)。 2. FACTORY METHOD 工厂方法模式 工厂方法模式:核心工厂
类
不再负责所有产品的创建,而是将具体创建的工作交给子
类
去做,成为
一个
抽象工厂角色,仅负责给出具体工厂
类
必须实现的接口,而不接触哪
一个
产品
类
应当被实例化这种细节。 请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要
一个
汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。 3. FACTORY 工厂模式 工厂模式:客户
类
和工厂
类
分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂
类
也要做相应的修改。如:如何创建及如何向客户端提供。 追MM少不了请吃饭了,麦当劳的ji翅和肯德基的ji翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个ji翅”就行了。麦当劳和肯德基就是生产ji翅的Factory。 4. BUILDER 建造模式 建造模式:将产品的内部表象和产品的生成过程分割开来,从而使
一个
建造过程生成具有不同的内部表象的产品
对象
。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 MM超级爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有
一个
多种语言翻译机,上面每种语言都有
一个
按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖) 5. PROTOTYPE 原型模式 原型模式允许动态的增加或减少产品
类
,产品
类
不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。缺点是每
一个
类
都必须配备
一个
克隆方法。 跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。 原型模式:通过给出
一个
原型
对象
来指明所要创建的
对象
的
类
型,然后用复制这个原型
对象
的方法创建出更多同
类
型的
对象
。 6. ADAPTER 适配器模式 适配器(变压器)模式:把
一个
类
的接口变换成客户端所期待的另一种接口,从而使原本因接口原因不匹配而无法一起工作的两个
类
能够一起工作。适配
类
可以根据参数返还
一个
合适的实例给客户端。 在朋友聚会上碰到了
一个
美女Sarah,从拉斯维加斯来的,可我不会说粤语,她不会说普通话,只好求助于我的朋友kent了,他作为我和Sarah之间的Adapter,让我和Sarah可以相互交谈了(也不知道他会不会耍我)。 7. BRIDGE 桥梁模式 桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在
一个
软件系统的抽象化和实现化之间使用组合/聚合关系而不是
继承
关系,从而使两者可以独立的变化。 早上碰到MM,要说早上好,晚上碰到MM,要说晚上好;碰到MM穿了件新衣服,要说你的衣服好漂亮哦,碰到MM新做的发型,要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题,自己用BRIDGE组合一下不就行了。 8. COMPOSITE 合成模式 合成模式:合成模式将
对象
组织到树结构中,可以用来描述整体与部分的关系。合成模式就是
一个
处理
对象
的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把
一个
个单独的成分
对象
和由他们复合而成的合成
对象
同等看待。 Mary今天过生日。“我过生日,你要送我一件礼物。”“嗯,好吧,去商店,你自己挑。”“这件T恤挺漂亮,买,这条裙子好看,买,这个包也不错,买。”“喂,买了三件了呀,我只答应送一件礼物的哦。”“什么呀,T恤加裙子加包包,正好配成一套呀,小姐,麻烦你包起来。”“……”,MM都会用Composite模式了,你会了没有? 9. DECORATOR 装饰模式 装饰模式:装饰模式以对客户端透明的方式扩展
对象
的功能,是
继承
关系的
一个
替代方案,提供比
继承
更多的灵活性。动态给
一个
对象
增加功能,这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 Mary过完轮到Sarly过生日,还是不要叫她自己挑了,不然这个月伙食费肯定玩完,拿出我去年在华山顶上照的照片,在背面写上“较好的的礼物,就是爱你的Fita”,再到街上礼品店买了个像框(卖礼品的MM也很漂亮哦),再找隔壁搞美术设计的Mike设计了
一个
漂亮的盒子装起来……,我们都是Decorator,最终都在修饰我这个人呀,怎么样,看懂了吗? 10. FACADE 门面(外观)模式 门面模式:外部与
一个
子系统的通信必须通过
一个
统一的门面
对象
进行。门面模式提供
一个
高层次的接口,使得子系统更易于使用。每
一个
子系统只有
一个
门面
类
,而且此门面
类
只有
一个
实例,也就是说它是
一个
单例模式。但整个系统可以有多个门面
类
。 我有
一个
专业的Nikon相机,我就喜欢自己手动调光圈、快门,这样照出来的照片才专业,但MM可不懂这些,教了半天也不会。幸好相机有Facade设计模式,把相机调整到自动档,只要对准目标按快门就行了,一切由相机自动调整,这样MM也可以用这个相机给我拍张照片了。 11. FLYWEIGHT 享元模式 享元模式:FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度
对象
。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部,不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态
不能
影响内蕴状态,它们是相互独立的。将可以共享的状态和不可以共享的状态从常规
类
中区分开来,将不可以共享的状态从
类
里剔除出去。客户端不可以直接创建被共享的
对象
,而应当使用
一个
工厂
对象
负责创建被共享的
对象
。享元模式大幅度的降低内存中
对象
的数量。 每天跟MM发短信,手指都累死了,最近买了个新手机,可以把一些常用的句子存在手机里,要用的时候,直接拿出来,在前面加上MM的名字就可以发送了,再不用
一个
字
一个
字敲了。共享的句子就是Flyweight,MM的名字就是提取出来的外部特征,根据上下文情况使用。 12. PROXY 代理模式 代理模式:代理模式给某
一个
对象
提供
一个
代理
对象
,并由代理
对象
控制对源
对象
的引用。代理就是
一个
人或
一个
机构代表另
一个
人或者
一个
机构采取行动。某些情况下,客户不想或者
不能
够直接引用
一个
对象
,代理
对象
可以在客户和目标
对象
直接起到中介的作用。客户端分辨不出代理主题
对象
与真实主题
对象
。代理模式可以并不知道真正的被代理
对象
,而仅仅持有
一个
被代理
对象
的接口,这时候代理
对象
不能
够创建被代理
对象
,被代理
对象
必须有系统的其他角色代为创建并传入。 跟MM在网上聊天,一开头总是“hi,你好”,“你从哪儿来呀?”“你多大了?”“身高多少呀?”这些话,真烦人,写个程序做为我的Proxy吧,凡是接收到这些话都设置好了自己的回答,接收到其他的话时再通知我回答,怎么样,酷吧。 13. CHAIN OF RESPONSIBLEITY 责任链模式 责任链模式:在责任链模式中,很多
对象
由每
一个
对象
对其下家的引用而接起来形成一条链。请求在这个链上传递,直到链上的某
一个
对象
决定处理此请求。客户并不知道链上的哪
一个
对象
最终处理这个请求,系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择:承担责任或者把责任推给下家。
一个
请求可以最终不被任何接收端
对象
所接受。 晚上去上英语课,为了好开溜坐到了然后一排,哇,前面坐了好几个漂亮的MM哎,找张纸条,写上“Hi,可以做我的女朋友吗?如果不愿意请向前传”,纸条就
一个
接
一个
的传上去了,糟糕,传到第一排的MM把纸条传给老师了,听说是个老一手女呀,快跑! 14. COMMAND 命令模式 命令模式:命令模式把
一个
请求或者操作封装到
一个
对象
中。命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的
对象
。命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否执行,何时被执行以及是怎么被执行的。系统支持命令的撤消。 俺有
一个
MM家里管得特别严,没法见面,只好借助于她弟弟在我们俩之间传送信息,她对我有什么指示,就写一张纸条让她弟弟带给我。这不,她弟弟又传送过来
一个
COMMAND,为了感谢他,我请他吃了碗杂酱面,哪知道他说:“我同时给我姐姐三个男朋友送COMMAND,就数你最小气,才请我吃面。” 15. INTERPRETER 解释器模式 解释器模式:给定
一个
语言后,解释器模式可以定义出其文法的一种表示,并同时提供
一个
解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了
一个
简单的文法后,使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器
对象
能够解释的任何组合。在解释器模式中需要定义
一个
代表文法的命令
类
的等级结构,也就是一系列的组合规则。每
一个
命令
对象
都有
一个
解释方法,代表对命令
对象
的解释。命令
对象
的等级结构中的
对象
的任何排列组合都是
一个
语言。 俺有
一个
《泡MM真经》,上面有各种泡MM的攻略,比如说去吃西餐的步骤、去看电影的方法等等,跟MM约会时,只要做
一个
Interpreter,照着上面的脚本执行就可以了。 16. ITERATOR 迭代子模式 迭代子模式:迭代子模式可以顺序访问
一个
聚集中的元素而不必暴露聚集的内部表象。多个
对象
聚在一起形成的总体称之为聚集,聚集
对象
是能够包容一组
对象
的容器
对象
。迭代子模式将迭代逻辑封装到
一个
独立的子
对象
中,从而与聚集本身隔开。迭代子模式简化了聚集的界面。每
一个
聚集
对象
都可以有
一个
或
一个
以上的迭代子
对象
,每
一个
迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。 我爱上了Mary,不顾一切的向她求婚。Mary:“想要我跟你结婚,得答应我的条件” 我:“什么条件我都答应,你说吧” Mary:“我看上了那个一克拉的钻石” 我:“我买,我买,还有吗?” Mary:“我看上了湖边的那栋别墅” 我:“我买,我买,还有吗?” Mary:“我看上那辆法拉利跑车” 我脑袋嗡的一声,坐在椅子上,一咬牙:“我买,我买,还有吗?” …… 17. MEDIATOR 调停者模式 调停者模式:调停者模式包装了一系列
对象
相互作用的方式,使得这些
对象
不必相互明显作用。从而使他们可以松散偶合。当某些
对象
之间的作用发生改变时,不会立即影响其他的一些
对象
之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将
对象
的行为和协作抽象化,把
对象
在小尺度的行为上与其他
对象
的相互作用分开处理。 四个MM打麻将,相互之间谁应该给谁多少钱算不清楚了,幸亏当时我在旁边,按照各自的筹码数算钱,赚了钱的从我这里拿,赔了钱的也付给我,一切就OK啦,俺得到了四个MM的电话。 18. MEMENTO 备忘录模式 备忘录模式:备忘录
对象
是
一个
用来存储另外
一个
对象
内部状态的快照的
对象
。备忘录模式的用意是在不破坏封装的条件下,将
一个
对象
的状态捉住,并外部化,存储起来,从而可以在将来合适的时候把这个
对象
还原到存储起来的状态。 同时跟几个MM聊天时,一定要记清楚刚才跟MM说了些什么话,不然MM发现了会不高兴的哦,幸亏我有个备忘录,刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存,这样可以随时察看以前的记录啦。 19. OBSERVER 观察者模式 观察者模式:观察者模式定义了一种一队多的依赖关系,让多个观察者
对象
同时监听某
一个
主题
对象
。这个主题
对象
在状态上发生变化时,会通知所有观察者
对象
,使他们能够自动更新自己。 想知道咱们公司**MM情报吗?加入公司的MM情报邮件组就行了,tom负责搜集情报,他发现的新情报不用
一个
一个
通知我们,直接发布给邮件组,我们作为订阅者(观察者)就可以及时收到情报啦。 20. STATE 状态模式 状态模式:状态模式允许
一个
对象
在其内部状态改变的时候改变行为。这个
对象
看上去象是改变了它的
类
一样。状态模式把所研究的
对象
的行为包装在不同的状态
对象
里,每
一个
状态
对象
都属于
一个
抽象状态
类
的
一个
子
类
。状态模式的意图是让
一个
对象
在其内部状态改变的时候,其行为也随之改变。状态模式需要对每
一个
系统可能取得的状态创立
一个
状态
类
的子
类
。当系统的状态变化时,系统便改变所选的子
类
。 跟MM交往时,一定要注意她的状态哦,在不同的状态时她的行为会有不同,比如你约她今天晚上去看电影,对你没兴趣的MM就会说“有事情啦”,对你不讨厌但还没喜欢上的MM就会说“好啊,不过可以带上我同事么?”,已经喜欢上你的MM就会说“几点钟?看完电影再去泡吧怎么样?”,当然你看电影过程中表现良好的话,也可以把MM的状态从不讨厌不喜欢变成喜欢哦。 21. STRATEGY 策略模式 策略模式:策略模式针对一组算法,将每
一个
算法封装到具有共同接口的独立的
类
中,从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模把行为和环境分开。环境
类
负责维持和查询行为
类
,各种算法在具体的策略
类
中提供。由于算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。 跟不同
类
型的MM约会,要用不同的策略,有的请电影比较好,有的则去吃小吃效果不错,有的去海边浪漫最合适,单目的都是为了得到MM的芳心,我的追MM锦囊中有好多Strategy哦。 22. TEMPLATE METHOD 模板模式 模板方法模式:模板方法模式准备
一个
抽象
类
,将部分逻辑以具体方法以及具体构造子的形式实现,然后声明一些抽象方法来迫使子
类
实现剩余的逻辑。不同的子
类
可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。先制定
一个
珠峰逻辑框架,而将逻辑的细节留给具体的子
类
去实现。 看过《如何说服女生上床》这部经典文章吗?女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method),但每个步骤针对不同的情况,都有不一样的做法,这就要看你随机应变啦(具体实现)。 23. VISITOR 访问者模式 访问者模式:访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话,接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统,它把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易,就是增加
一个
新的访问者
类
。访问者模式将有关的行为集中到
一个
访问者
对象
中,而不是分散到
一个
个的节点
类
中。当使用访问者模式时,要将尽可能多的
对象
浏览逻辑放在访问者
类
中,而不是放到它的子
类
中。访问者模式可以跨过几个
类
的等级结构访问属于不同的等级结构的成员
类
。 情人节到了,要给每个MM送一束鲜花和一张卡片,可是每个MM送的花都要针对她个人的特点,每张卡片也要根据个人的特点来挑,我
一个
人哪搞得清楚,还是找花店老板和礼品店老板做一下Visitor,让花店老板根据MM的特点选一束花,让礼品店老板也根据每个人特点选一张卡,这样就轻松多了。
C++中定义
一个
不能
被
继承
的
类
一种错误的解法 最开始是从构造函数开始着手(先声明这种方法
不能
定义
一个
不能
被
继承
的
类
,这是一种错误的方法,但是很容易往这方面想),假设存在下面的
继承
体系: 现在假设B是
一个
不能
被
继承
的
类
,那么如果存在B的子
类
C,那么C的构造过程应该会报错,那么如何能够让B能正常构造而C
不能
正常构造呢?首先A,B,C的构造函数和析构函数都假设是public的,最开始想的是让B私有
继承
自A,根据priva
c++之哪些成员函数
不能
被
继承
C++中,并不是所有的成员函数都能被子
类
继承
,有三
类
成员函数
不能
被子
类
继承
,分别是:构造函数(包括拷贝构造)、析构函数、赋值运算符重载函数。 一,构造函数 构造方法用来初始化
类
的
对象
,与父
类
的其它成员不同,它
不能
被子
类
继承
(子
类
可以
继承
父
类
所有的成员变量和成员方法,但不
继承
父
类
的构造方法)。因此,在创建子
类
对象
时,为了初始化从父
类
继承
来的数据成员,系统需要调用其父
类
的构造方法。 如果没有显式的构造函数,编译器会给
一个
默认的构造函数,并且该默认的构造函数仅仅在没有显式地声明构造函数情况下创建。 ..
枚举
类
能
继承
吗?能被
继承
吗?
枚举的作用:限定“数据集”中的元素的个数(将
类
理解为
一个
集合)、即限定枚举
类
对象
的个数。 如果
一个
类
的实例是有限且确定的,那么可以使用枚举
类
。比如:季节
类
,只有春夏秋冬四个实例。 枚举
类
与普通
类
的区别: 1.枚举
类
也是
类
,也可以有自己的成员变量,成员方法,静态方法、静态变量等,也能实现其他的接口,
不能
继承
其他
类
了(因为已经
继承
了java.lang.Enum)。枚举
类
的
对象
默认都是public...
String
类
能被
继承
吗,为什么?
不能
被
继承
,因为String
类
有final修饰符,而final修饰的
类
是
不能
被
继承
的。 Java对String
类
的定义: final修饰符的用法: 1.修饰
类
当用final修饰
一个
类
时,表明这个
类
不能
被
继承
。final
类
中的成员变量可以根据需要设为final,但是要注意final
类
中的所有成员方法都会被隐式地指定为final方法。 2.修饰方法 使用final修饰方法的原因有两个。第
一个
原因是把方法锁定,以防任何
继承
类
修改它的含义;第二个原因是效率。在早期的Java实现版本中,
C++ 语言
64,684
社区成员
250,491
社区内容
发帖
与我相关
我的任务
C++ 语言
C++ 语言相关问题讨论,技术干货分享,前沿动态等
复制链接
扫一扫
分享
社区描述
C++ 语言相关问题讨论,技术干货分享,前沿动态等
c++
技术论坛(原bbs)
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
请不要发布与C++技术无关的贴子
请不要发布与技术无关的招聘、广告的帖子
请尽可能的描述清楚你的问题,如果涉及到代码请尽可能的格式化一下
试试用AI创作助手写篇文章吧
+ 用AI写文章