今天你抽象了吗?

本文探讨了抽象在思维和学习中的重要性,通过实例展示了如何将复杂知识抽象为易于理解和管理的概念,以及抽象思维如何影响个人的学习效率和思维深度。同时,文章结合编程领域的面向对象思想,阐述了抽象在解决问题过程中的作用。

      由于没有了网络,信息变得不顺畅,和外界的沟通也少,写个博客都没有办法发表。昨天碎碎念了一小下,嘻嘻.. 

     最早接触抽象就是在美术课上,有个什么抽象派。但是再多的就不是很了解了,后来就是在TGB学习面向对象的时候,接触过的OOP核心——抽象。

     计算机中我们是这么做的:把一个现实中相似的事物(对象)抽象成一类,这个类有相同的属性和操作。

 

    下午和11期开自考小会的时候,脑袋里忽然有一个问题,两期的同学有什么区别呢?为什么在师傅感觉很简单的问题在徒弟看来会非常的难呢?

 

     是否因为智力呢?答案当然不是,除了因为师傅的见闻和知识量比徒弟的多之外,更多的原因是师傅们的抽象能力比徒弟更高一些,在这么多次的考场厮杀中,师傅们已经学会了让自己的事情变少,时间变多。这是怎么做的呢?


拿自考来举例。

首先,老老实实的把书从头到尾的看一遍,然后拿出两个番茄的时间,画一张导图,从总体的角度来对整本书把握一下,如果你感觉自己脑子还是一片空白,没有关系,后面还要继续学习。

然后就是在第二个阶段学习了,这个阶段时间长一些,比第一遍多两三倍的时间来细细的看,这个时候,你会有点晕晕的,虽然感觉有的地方比较熟悉,但是知识好像越学越多了,这个状态就说明对了,抽象就是你最好的朋友,从小细节开始自底向上抽象,遇到共同点多的就归并为一个。然后一层一层的,这样你就会得到一个根节点——书名,在这个过程中,就完成了整本书抽象的过程。

                      

两个阶段下来,你的知识就从少变多,然后由多变少。

                       


我想这就是米老师说的读书吧。

     其实,今天给我最大的感受不是来自于学习上的,而是抽象对于思维的影响。以前我们老说“一件事没办法用言语表达了或者只可意会不可言传”在很大程度上这些话在遮掩着说明词穷了。呵呵,如果你有这样的情况一定要注意喽!

看到过一些人,废话不多,但是字字珠玑,当他说出一句话的时候,我们都要捉摸半天,是不是有什么大道理在里面,他是怎么想的,今天我是恍然大悟了——这是抽象的魅力啊。平时就养成一种抽象的思维习惯,每多接触一件事的时候,都不会是全新全未知的东西,这些东西积累多了,那么他就真的变成一个活百科了,那他出口成章,条条在理就不奇怪了。

 

抽象,引领思维方式。


     还记得前两天米老师讲PV操作,我当时只知道这是操作系统里的一个知识点,其他一片空白呢!经过米老师讲解之后就理解了两个进程进行操作,解耦和后,生产者和使用者,在排队和使用两个状态转换的关系,虽然中间有一些插曲,但是让我对于抽象的魅力又有了一次真实的体会。


                  

真的抽象出这么一个概念后,不管过了多长时间,是否出错,从抽象根节点出发,就会找到问题,和从生活中找到任何一个实例化的例子——12306和乘客。食堂和学生。

 

今天你抽象了吗?



### ER图中联系是否必须抽象为实体的设计原则和规范 在ER图(实体关系图)的设计中,联系是否需要抽象为实体取决于具体的应用场景以及数据建模的需求。以下是关于这一问题的专业分析: #### 1. 联系抽象为实体的必要性 并非所有联系都需要抽象为实体。通常情况下,只有当联系本身具有独立的属性或需要进一步描述时,才将其抽象为实体[^1]。例如,在某些复杂业务场景中,联系可能包含额外的信息,这些信息无法简单地通过两个实体之间的关联来表达。此时,将联系抽象为实体可以更好地组织和管理数据。 #### 2. 设计原则 - **简单性**:如果一个联系仅表示两个实体之间的关联,并且没有附加属性,则无需将其抽象为实体[^2]。 - **功能性**:当联系需要存储额外的数据或支持复杂的查询操作时,应考虑将其抽象为实体。这种设计能够提高数据库的灵活性和可扩展性。 - **规范化**:在概念设计阶段,目标是构建一个高层次的数据模型,避免与特定应用程序绑定。因此,对于具有多对多关系的情况,通常建议将其分解为两个一对多关系并通过引入中间实体来实现[^1]。 #### 3. 规范示例 以下是一个简单的代码示例,展示如何在数据库设计中处理联系是否抽象为实体的问题: ```sql -- 示例1:未将联系抽象为实体 CREATE TABLE Students ( StudentID INT PRIMARY KEY, Name VARCHAR(100) ); CREATE TABLE Courses ( CourseID INT PRIMARY KEY, Title VARCHAR(100) ); -- 表示学生选课的一对多关系 CREATE TABLE Enrollments ( StudentID INT, CourseID INT, FOREIGN KEY (StudentID) REFERENCES Students(StudentID), FOREIGN KEY (CourseID) REFERENCES Courses(CourseID) ); -- 示例2:将联系抽象为实体 CREATE TABLE EnrollmentDetails ( EnrollmentID INT PRIMARY KEY, Grade CHAR(2), -- 新增属性:成绩 StudentID INT, CourseID INT, FOREIGN KEY (StudentID) REFERENCES Students(StudentID), FOREIGN KEY (CourseID) REFERENCES Courses(CourseID) ); ``` 在上述代码中,`EnrollmentDetails` 是一个将联系抽象为实体的例子,因为它包含了额外的属性 `Grade`,用于记录学生的成绩信息。 #### 4. 总结 联系是否需要抽象为实体取决于其复杂性和功能需求。在实际应用中,应遵循简单性、功能性和规范化的原则,以确保数据库设计既高效又灵活[^1]。
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值