选择的OOP抽象必须尽可能接近生命吗?

我正在为我的应用程序设计一个库,它包装了Windows智能卡子系统。

在物理上,有一个智能卡,它连接到智能卡读卡器,读卡器连接到PC。有许多类型的智能卡(例如JavaCards和.NET卡)。设计方法如下:

跑步机列表库<-跑步机列表Javacard

跑步机数据库<-跑步机Javacard

tsmartcardbase<-TjavaCard卡

按索引或名称返回读卡器的readers'get()方法列表,读卡器的方法connect()返回要使用的卡对象实例。

问题是,虽然智能卡的物理类型确实不同,但实际上只有一种读卡器类型可以读取所有智能卡。TreaderlistJavaCard只是使用特定的JavaCard属性执行搜索功能。在connect()方法中,treaderJavaCard只返回TjavaCard类的实例,而不返回tsmartcardBase。

此外,这种设计还有一些逻辑漏洞,例如,当您将智能卡从读卡器中拔出时,tsmartcardbase子代实例可能会立即被销毁,因为类名表示它模拟卡本身,而此卡已不复存在。

TT确实有效。但是这个计划看起来合乎逻辑吗?

我的朋友建议我重新设计一个系统,如下所示:

跳过读卡器,创建一个tsmartcardProxyObjectBase类,从中降下TjavaCardProxyObject,并添加搜索和连接卡的所有方法。类似于一体式包装。这个抽象看起来很好,因为cardproxyobject确实可以搜索某个东西,连接到某个东西,离线(如果卡,它连接到的卡被删除了)等等,但是这个设计违反了srp,因为一个类同时进行通信和对象搜索。如果我想从中分离搜索函数,我会得到与第一种情况相同的方案(它只会添加一些可以与读者一起工作的东西)。

我的朋友说,我们实际上并不直接与读者合作,图书馆的主要目标是使用卡片,因此我们应该将读者隐藏起来,不让图书馆用户看到。

因为这样的项目是你可以从中学习OOP设计的,所以我有兴趣找到一个晶莹美丽的解决方案;)

我希望我能解释一切可以理解的;)

这是第三种方法。让它成为最终的读者列表和读者类。但在阅读器中不应该有connect()方法。相反,我可以在智能卡类中实现use()或putonline()方法,以使用这个特定的读卡器进行有效地隐藏用户的低级scardconnect调用。搜索函数可以移到一旁的某个助手类中(如TjavaCardLocatorService)。还是应该让它们成为TjavaCardProxyObject类的静态成员?类似于tjavacardproxyobject.attachTocardWithAID(readerList),但是这个名字看起来也不合逻辑,而且似乎再次违反了SRP。

你怎么认为?在现实生活中,拥有一个好的架构有什么重要的意义吗?或者我只是在浪费时间去学习一些不重要的东西?