伟大的抽象/具体二分法

最新推荐文章于 2025-09-03 09:06:17 发布
原创 最新推荐文章于 2025-09-03 09:06:17 发布 · 421 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#weblogic #jvm #websphere #oracle #数据库 #ibm

面向对象设计中有一条原则叫做依赖倒置，意思就是要依赖抽象，而不是依赖具体。这让我联想到了"抽象/具体二分法"这个命题，当然我只能感慨，真TMD 伟大。

小了说，接口/实现是二分法的一种体现，这种做法已经为我们设计时解耦合做出了巨大的贡献。

当然，真正伟大的还是规范/实现这对玩意儿。

首先讲讲我们熟悉的Java，

JVM 本身是一组规范(当然很多地方也用JVM 来表示JVM 的实现),而其实现有IBM JVM,SUN Hotspot JVM,Oracle JRocket 等。

J2EE 也是一组规范，其实现有IBM Websphere,Oracle Weblogic,Redhat Jboss... 想想Weblogic 和Jboss 当初都是SUN 公司里面一个跑出来一个大牛，搞出一个J2EE 实现，最终成就大业，如今SUN 已是昨日黄花，不禁唏嘘。当然我相信Java 是不会倒下的。

再说说我们的操作系统，

POSIX 标准簇应该如雷贯耳吧，UNIX 和各式Linux 都是它的实现。

再说说我们的数据库，

SQL 规范应该也是如雷贯耳吧，其实现就不得了了，DB2,Oracle,MS SQL... ...

 

这本身还不足以让人感慨，最重要的是，上面讲了这么多的实现，如果大家不是遵循同样的规范，很难想象现在的世界是个什么样子，可能软件开发人员一半的时间都要去学工具了。而现在，相对来说，大家还是活的很惬意的，

  • 用Java 写出来的东西真的很容易移植
  • 掌握一种操作系统后，要转换一种系统，基本没什么障碍
  • 掌握一种数据库，要转换另外一种数据库，至少在开发层面上学习曲线还是可以接受的(管理就不一定了，哈哈)

想想这些为人类节省了多少的智力成本啊，伟大都不足以形容... ...

 

 

设计杂谈(0x02)——约定大于配置
HansBug的私家疯人院~~~
07-12 591
“约定大于配置”设计思想，及其在配置文件的设计中的应用，为该系列的第二篇。
SpringBoot的“约定优于配置”理念详解
LiuYuHao_的博客
02-15 961
约定优于配置是一种软件设计哲学，旨在通过提供一组合理的默认配置来减少开发者需要做出的选择，从而简化开发过程。具体来说，这种理念假设大多数项目都会遵循一些常见的模式和惯例，因此框架会预先设定这些模式和惯例的默认值，开发者只需在特殊情况下进行自定义配置。虽然Spring Boot提供了很多默认配置，但在某些情况下，你可能需要自定义配置。你可以通过或文件来覆盖默认值。
约定优于配置（convention over configuration），按约定编程
Jaylon Wang的专栏
08-27 3680
约定优于配置   约定优于配置（convention over configuration），也称作按约定编程，是一种软件设计范式，旨在减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。 本质是说，开发人员仅需规定应用中不符约定的部分。例如，如果模型中有个名为Sale的类，那么数据库中对应的表就会默认命名为sales。只有在偏离这一约定时，例如将该表
零配置 之 21.2 约定大于配置
IT忍者神龟
05-06 865
21.2  约定大于配置 21.2.1  约定大于配置的HelloWorld 先来做一个示例，让大家体会一下什么是约定大于配置。 1：Convention Plugin 从Struts2.1版本起，Struts2官方就推荐使用Convention Plugin替换Codebehind Plugin来实现零配置。相对Codebehind Plugin而言，Convention Plugin
约定大于配置
很皮的博客
09-07 2593
约定大于配置 约定大于配置，也可以叫做约定优于配置（convention over configuration），也称作按约定编程，是一种软件设计范式，指在减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。 本质是说，开发人员仅需规定应用中不符约定的部分。例如，如果模型中有个名为Sale的类，那么数据库中对应的表就会默认命名为sales。只有在偏离这一约定时，例如将该表命名为"pro...
晚期罗马共和国：形而上学抽象性的起源
### 晚期罗马共和国：形而上学抽象性的起源 #### 1. 海德格尔视角下的罗马思想 海德格尔强调了关注罗马对世界布局的认知 - 本体论过程的重要性，他认为罗马的唯物主义立场体现在其对现实的理解和处理方式上。罗马人...
19、本土经济学与伟大的经济融合：迈向新经济时代
u8v9w0x1y的博客
09-02 68
本文探讨了传统经济模式在全球多重危机下的局限性，并提出了以本土经济学和新经济运动为核心的解决方案。文章强调了经济与生态、社会的深度融合，倡导以意义经济为核心，推动合作、共享和可持续发展。通过借鉴本土世界观的智慧，文章呼吁构建一个更加包容、平衡和以人为本的新经济体系，以应对全球性挑战并实现人类福祉的提升。
java基础面经--下
天才小熊猫的客栈
07-05 1124
24、反射的实现与作用 Java语言编译之后会生成一个.class文件，反射就是通过字节码文件找到某一个类，类中的方法以及属性等。反射的实现主要借助以下四个类： Class:类的对象 Constructor：类的构造方法 Field:类中的属性对象 Method:类中的方法对象 作用：反射机制指的是程序在运行时能够获取自身的信息。在java中，只要给定类的名字，那么就可以通过反射机制来获取类的所有信息。 25、注解的原理 注解本质是一个继承了Annotation 的特殊接口，其具体实.
15、道德哲学与教育中的爱与思考
c7d8e的博客
09-02 58
本文探讨了道德哲学与教育中的核心价值，分析了Holland、Winch、John Cook等学者对道德理解与相对主义的思考，强调个人在道德决策中的独立性。同时，文章深入阐述了教育中教师对学科的热爱如何激发学生对世界的爱，并通过Martin Winkler等实例展现教育的情感与精神维度。结合希望与乐观的区别，以及爱在应对社会困境中的力量，文章呼吁重视传统价值、推动去殖民化变革，促进教育与道德哲学的融合发展，以构建更公正、充满希望的未来。
3、科学领导权的转移：从欧洲到美国及量子物理的哲学思考
最新发布
o0p1q2r3的博客
09-03 29
本文探讨了20世纪科学中心从欧洲向美国转移的历史进程，分析了纳粹上台导致大批科学家移民美国及其对全球科学格局的深远影响。文章对比了欧洲注重哲学思辨与美国强调实用主义和数学应用的不同科研风格，并深入探讨了量子物理中的核心哲学问题，包括现实本质、测量难题、广义相对论与量子力学的统一、宇宙学理论及暗物质与暗能量之谜。同时展望未来科学发展需融合哲学思考、实验创新、人工智能可解释性研究与国际合作，以推动科学持续进步。
什么是约定大于配置
m0_73875507的博客
06-06 2224
反之，可以配置来达到所期待的方式。SpringBoot的约定大于配置，按我的理解是：对比SpringMVC，需要在web.xml里面配置前端控制器，还需要在核心配置文件（*-servlet.xml）中配置视图解析器啥的，更要配置第三方的Tomcat服务器。一句话总结来说，约定大于配置就是一种开发原则，就是为了减少人为的配置，能使用默认配置就使用默认配置，默认配置其实就是所谓的“约定”。当存在特殊需求的时候，我们再自行自定义配置覆盖掉默认配置即可，这样就可以大大的减少配置工作，提高我们的工作效率。
SpringBoot约定大于配置理解
lxh650的博客
08-01 1万+
       约定大于配置是一种开发原则，就是减少人为的配置，直接用默认的配置就能获得我们想要的结果。         SpringBoot的约定大于配置，按我的理解是：对比SpringMVC，需要在web.xml里面配置前端控制器，还需要在核心配置文件（*-servlet.xml）中配置视图解析器啥的，更要配置第三方...
约定大于配置到底是什么意思？
热门推荐
Xiao_Jin_Ling的博客
10-31 1万+
约定大于配置到底是什么意思？ 今天突然想起来，之前学springboot的时候，经常听到看到约定大于配置，也没有深究过，所以他到底是啥意思呢？ 百度百科：约定大于配置，也可以叫做约定优于配置（convention over configuration），也称作按约定编程，是一种软件设计范式，指在减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。 看了百度百科以后呢，其实我还是有亿点点蒙，然后又去查了查，我的理解： 1.约定是什么意思？ 在开发的时候，很多时候有些东西如果你没有配置的话，程
何谓 “约定大于配置”
05-17 548
约定大于配置 第一次听到这个说法还是在学习springboot时，刚开始的时候只是知道在程序的世界中有这个说法，也没有去深究它的意思。 约定？ 对于我们人来说，能够满足大多数人的习惯的约定就是一种好的约定，而在程序中，能够简化代码的实现，使代码高可用的约定就是一种好的约定。 约定大于配置 其实在开发中，处处都用到了“约定大于配置”这一思想 就是在开发中，如果有些值你没有配置的话，那程序会取一个默认值，换句话说，能取默认值的配置，就不需要配置了，这个默认值就是约定。 约定可以减...
“约定大于配置”（Convention over Configuration）是软件开发中的一种设计理念，旨在通过定义合理的默认约定来减少显式配置，从而简化开发流程
专注于前沿技术的探索与实践，热衷于从代码逻辑、架构设计到行业应用等多维度深挖技术本质。期待在技术之路上与你共同成长～
05-19 803
仓储：ABP的仓储模式遵循约定，仓储接口定义在领域层（`.Domain`），实现类放在基础设施层（`.Infrastructure`）。约定大于配置通过标准化的命名和结构（例如，实体类放在`Domain`层，仓储接口以`IRepository`结尾），确保团队成员遵循相同的语言和模式。- DTO：数据传输对象（DTO）通常放在`.Application.Contracts`中，约定以`Dto`结尾（如`ProductCreationDto`）。例如，领域事件可以通过约定自动发布和订阅。
如何理解约定大于配置
H_hello_world的博客
10-19 2665
       很多刚刚接触到框架的同学，都应该对这个约定大于配置这六个字有着不少的疑惑，个人从网上也找了些不同的见解。        简单来说，就是能使用默认，就使用默认。当存在特殊需求的时候，自定义配置即可。这样可以大大的减少配置工作，这就是所谓的“约定”。        例如spring boot
Spring Boot “约定大于配置”
Mr.W的博客
02-14 2179
约定大于配置”是一种简化开发的设计理念。简单来说，就是框架默认提供了常见的配置和行为，开发者只需要按照约定来编写代码，避免了繁琐的配置，只在需要时进行定制和调整。这种理念在Spring Boot中被充分体现，开发者可以专注于业务逻辑的开发，而不必在配置文件中花费大量精力在Spring Boot中，这一理念通过自动配置（Auto Configuration）和默认约定得到了广泛应用，极大地简化了应用的搭建过程。
如何将七类情感映射为传统的积极/消极二分法？
04-26
<think>嗯，用户问的是如何将七类情感映射到传统的积极/消极二分法。首先，我需要明确七类情感具体指的是哪些。通常，情感分类可能有不同的模型，比如Ekman的六种基本情感（愤怒、厌恶、恐惧、快乐、悲伤、惊讶），或者其他的扩展。不过用户提到的是七类，可能是指另一种分类，比如七种基本情感，比如快乐、悲伤、愤怒、恐惧、惊讶、厌恶和中性，或者可能是其他组合。需要先确定这七类具体是什么。 假设这里的七类情感是常见的扩展版本，比如：快乐、悲伤、愤怒、恐惧、惊讶、厌恶和中性。那接下来需要将这些情绪分为积极和消极两类。通常，快乐属于积极，而悲伤、愤怒、恐惧、厌恶属于消极。惊讶可能根据上下文是中性的，但有时也被归为消极或积极，需要看具体情况。中性可能单独处理，或者根据需求归为某一类。接下来，用户可能需要一个映射方法，比如建立一个字典，将每个情感类别对应到二分法的类别。同时，可能要考虑如何处理中性或不确定的情感，比如将其忽略，或者归为消极或积极中的某一类。 然后，可能需要代码示例，比如用Python编写一个函数，接收原始情感标签，返回二分法的结果。比如使用字典映射，或者更复杂的逻辑，比如基于概率的分类，如果有置信度分数的话。 另外，需要考虑如何处理不在预设七类中的情况，可能需要默认值或者异常处理。可能的代码结构是创建一个映射字典，将每个情感类别映射到积极或消极。然后编写一个函数，输入原始情感，输出对应的二分标签。例如： ```pythonemotion_mapping = {'happy': 'positive', 'joy': 'positive', 'sadness': 'negative', 'anger': 'negative', 'fear': 'negative', 'disgust': 'negative', 'surprise': 'neutral', #或者根据需求调整'neutral': 'neutral'} def map_to_binary(emotion): binary= emotion_mapping.get(emotion, 'neutral')# 默认处理未知情感# 如果要求必须分为积极或消极，可以将surprise和neutral归为某一类，或者排除return binary``` 但用户可能需要将所有七类归为积极或消极，没有中性。这时候可能需要调整，例如将surprise归为积极或消极。例如，根据某些研究，惊讶可能短暂且不一定负面，但有时可能伴随负面情绪，所以可能需要根据具体应用场景决定。 此外，可能需要处理的情况包括情感强度，如果有的话，但问题中没有提到，所以可能不需要。 另一个考虑是，是否允许某些情感同时属于积极和消极，但二分法通常是非此即彼的，所以每个情感只能属于一类。 可能的代码示例： 假设七类情感为：快乐（happy）、悲伤（sadness）、愤怒（anger）、恐惧（fear）、惊讶（surprise）、厌恶（disgust）、信任（trust）。这里信任属于积极，惊讶可能归为中性，但根据用户需求调整。 或者，可能用户提到的七类情感是另一种分类，需要确认。但根据常见情况，假设七类包括快乐、悲伤、愤怒、恐惧、厌恶、惊讶和中性。那么映射可能如下： - 积极：happy -消极：sadness, anger, fear, disgust- 中性：surprise,neutral 但用户需要的是二分，所以可能需要将中性也归为消极或积极，或者排除。例如，在二分法中，可能将中性忽略，或者归为消极，但这样可能不准确。所以需要明确用户的需求。 假设用户希望将七类情感严格分为积极和消极，那么可能的映射是：happy → positivesadness,anger, fear,disgust → negative而如何处理surprise和neutral？如果原七类中没有neutral，可能需要明确。比如，七类可能是：快乐、悲伤、愤怒、恐惧、惊讶、厌恶、信任。那么信任属于积极，惊讶可能根据情况处理。但为了简化，可能用户的问题中的七类不包括中性，所以惊讶可能需要归为某一类。例如，在某些情况下，惊讶可能被视为中性，但为了二分法，可能需要强制归类。比如，将惊讶归为消极，因为有时惊讶可能伴随负面事件。或者，根据具体应用场景，例如在商品评论中，惊讶可能更多是积极的（比如惊喜），所以归为积极。因此，可能需要用户提供更多上下文，但在缺乏信息的情况下，需要做出合理假设。 总结步骤：1. 确定七类情感的具体类型。 2.将每个类别映射到积极或消极。 3.处理可能的边缘情况（如中性或惊讶）。 4. 编写映射函数，可能使用字典。 5.提供代码示例和解释。 可能的代码： ```python# 定义七类情感到二分法的映射（假设七类为happy, sadness,anger, fear,disgust, surprise,neutral） emotion_to_binary ={ 'happy': 'positive','sadness': 'negative', 'anger': 'negative','fear': 'negative','disgust': 'negative','surprise': 'positive',# 假设惊喜归为积极'neutral': 'neutral'# 如果必须二分，可归为某一边或排除 }def convert_to_binary(emotion): #如果必须返回positive或negative，处理neutral情况return emotion_to_binary.get(emotion, 'neutral') #或者抛出错误# 示例使用emotions =['happy', 'anger', 'surprise', 'neutral'] binary_emotions = [convert_to_binary(e) for e inemotions] print(binary_emotions) # ['positive', 'negative', 'positive','neutral'] ```但根据用户的问题，可能需要将所有七类都映射到积极或消极，所以可能需要调整，比如将surprise和neutral归为积极或消极。例如： ```pythonemotion_to_binary = {'happy':'positive','sadness': 'negative','anger':'negative','fear':'negative','disgust':'negative','surprise':'positive',# 假设惊喜是积极'neutral': 'negative' #假设中性归为消极 }def convert_to_binary(emotion): return emotion_to_binary.get(emotion,'negative')# 默认处理未知为negative# 测试print(convert_to_binary('happy')) # positiveprint(convert_to_binary('neutral')) #negative print(convert_to_binary('unknown'))# negative ```这样，所有七类都被映射，并且未知情感默认归为消极。解释部分需要说明每个情感归类的理由，比如根据常见情感分析的研究或应用场景。例如，快乐显然是积极，而其他如愤怒、悲伤等属于消极。惊讶可能根据具体情境，但在此假设为积极（如惊喜）。中性可能根据需求处理，这里假设归为消极。 相关问题可能涉及如何处理不确定的情感、其他分类方法、使用机器学习进行自动分类、或者在不同语言中的实现等。</think>以下是七类情感到积极/消极二分法的典型映射方案及实现代码： ```python # 定义七类情感到二分类的映射字典 EMOTION_MAPPING = { # 积极情感 "joy": "positive", "love": "positive", "surprise": "positive", # 假设惊喜场景 # 消极情感 "anger": "negative", "sadness": "negative", "fear": "negative", "disgust": "negative" } def map_emotion(emotion): """将七类情感映射为二分法""" return EMOTION_MAPPING.get(emotion.lower(), "unknown") # 示例使用 if __name__ == "__main__": emotions = ["joy", "Anger", "surprise", "fear", "neutral"] results = [(e, map_emotion(e)) for e in emotions] for original, mapped in results: print(f"{original:8} -> {mapped:8}") ``` 代码解释： 1. 创建映射字典`EMOTION_MAPPING`，其中： - joy/love/surprise 映射为 positive - anger/sadness/fear/disgust 映射为 negative 2. `map_emotion()`函数实现核心映射逻辑： - 使用`.lower()`统一输入格式 - 使用字典的`get()`方法处理未知情感（返回"unknown"） 3. 示例演示如何处理大小写不一致和未知情感 典型映射依据： - **积极类**包含明确的正向情绪： - joy（喜悦）：核心积极情绪 - love（爱）：强烈正向情感 - surprise（惊讶）：假设为正向的"惊喜"场景 - **消极类**包含所有负面情绪： - anger（愤怒）、sadness（悲伤）、fear（恐惧）、disgust（厌恶）都是典型的负面情绪
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值