Java程序设计第一阶段总结

Java程序设计第一阶段总结 

第一阶段我们学习了很多，也做了很多作业

本篇文章根据时间顺序总结学习内容。PTA另算(￢_￢)

目录：

PTA作业总结：

程序设计：

　　1.例题介绍：

　　2.类的设计：

　　　　第一次类设计：

 

　　　　第二次类设计：

　　　　　　　　1：单一功能原则SRP

　　　　　　　　2：三种类

　　　　　　　　3：迪米特原则

　　　　　　　　4：关联、聚合、组合、耦合性。

　　　　第三次类设计：

　　　　　　MVC设计模式

　　　　第四次类设计：

　　　　　　　　1.抽象类

　　　　　　　　2.继承

　　　　　　　　3.单例模式

　　　　　　　　4.里氏代换原则

　　　　第五次类设计：

　　　　　　　　多态

 

　　我滴总结

　　七个设计原则总结：

　　

 

 

 

PTA作业总结：

PTA作业更偏向解决问题，再做作业时我很少用到类的设计，因为大多数题目在不使用类的设计时，会更简单，更高效。

也可能是java刚入门的原因，第一阶段的作业只是为了巩固我们的java语法基础。

但是！

有些题目并不难，它的测试点却非常严密，例如：

输入一个浮点数，判断它输入是否合法：

1.0 -1.0 -0 0.0 -01.0

以上是我能想到的测试点，这些奇怪的测试点在题目中都出现过。

第一次做的时候完全想不到，01.0这种数字要判非法输入。

 

例题介绍：

 

根据上如设计一个雨刷控制程序。

根据控制杆的档位和刻度盘的速度来控制雨刷的速度。

要求：1.要有显示界面 2.加档减档必须是连续的（一次只能加或减一档）

第一次作业：

实现雨刷控制

这一次作业是在第一次上课后写的，第一次上课为我们简单介绍了下“类”这个概念。

不幸的是，开学第一周，我从省外返校，我被隔离了TAT

所以我第一次作业用到的全是我网上学习的知识。

首先类应该有个构造方法，然后对于他的属性应该有获取和修改的方法。

enmmm，就酱紫吧。。。

 

 

通过网上的自学，我模模糊糊了解到，几个不同的东西应该分开。

所以给三个东西设计成了不同的类，对于Uesr类，也只是认为应该有一个东西把这几个东西联结起来

可以说这个作业勉勉强强达到了能运行，能显示界面，能根据表盘和档位控制速度这几个要求。

垃圾代码就不放上来了。

 

第二次作业：

 第二次作业是我的第一次线下课(〃＞皿＜）

先总结下第二次作业前，我们学到了什么：

1.功能单一原则

2.类的分类

3.迪米特法则

4.类之间的关系（1）

那么就按照这个顺序来讲吧：

 

一、功能单一原则SRP：

核心思想：解耦和增强内聚性（高内聚，低耦合）

类被修改的几率很大，因此应该专注于单一的功能。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题

说人话：一个函数只实现一个功能，一个类也只实现一个功能。

总结几个新手容易犯的错误。

例如，我的加减档函数，他的功能只是加减档，而不会有判断是否到最大挡或最小档。

再例如，我的显示函数，他的功能只是显示数据，而不会计算雨刷刻度。

还有个新手容易犯的错误，挖个坑 buling~buling~

 

二、类的分类

有三种类：实体类，业务类，接口类。

实体类：像是雨刷，档位，刻度这种确实存在的。应该属于实体类。

业务类：又称控制类，它的作用是控制实体类，是不存在的。

接口类：暂时木有讲(⊙︿⊙)

 

三、迪米特法则

又称最少知识原则

核心思想：一个对象应当对其他对象有尽可能少的了解,不和陌生人说话

降低各个对象之间的耦合，提高系统的可维护性

说人话：设计的类应该尽可能独立

例如、我的刻度盘应该是独立的，他和其他类没有任何关系，没有调用其他类。

 

四、类之间的关系（1）

第一次只讲了部分

关联：

关系比较紧密；
本质是 调用方法；
类图中用箭头表示

聚合：（分为组合和聚合两种）

整体和部分间的关系。
用菱形和箭头表示
空心聚合，聚合的组成部分与整体生存期可以不一样
实心组合，整体和部分的生存期一致；

还引入了“耦合性”这个概念。

耦合性：

指类之间关系的紧密程度。（个人理解）

好的设计因该是尽可能的降低各个类之间的耦合性。

 

根据以上所学内容，我的第二次作业：

 

 

 

 

  非常好【自嗨】

可以看到现在的设计已经有模有样了，各个类的功能比较完全，类之间的关系也比较明确。

如果作业是100满分，我觉得我这个已经70分以上了【自嗨】

 

 

第三次作业：

通过第三次学习，我先来批判一下上次作业( ﹁ ﹁ ) ~→

井底之蛙，呱呱呱。什么70分。

又是新手容易犯的错误，仔细看，控制类里是不是多了什么？

没错，控制类里怎么会有print。。。。

这个符合单一职责吗？不符合。。。

control类应该只负责控制雨刷速度，加档换挡，加速减速。只负责控制车子。

print这个功能不应该是control类该做的。

那么print该谁来做呢？

诶嘿，由此引入MVC设计模式。（不是原则嗷）

（一共23中设计模式）

 

MVC设计模式：

MVC是model view controller的缩写

又称entity GUI control

分别是实体，图像界面，控制的意思

思想核心：实体类，显示类，控制类分开设计

其中显示类和控制类都应该是属于业务类，不是真实存在滴。

 

所以我的print应该属于新加的一个输出类里。

所以上次作业……咳咳0分滚蛋！

 

 这一次次的作业就是修改上一次的作业，使他再正确一点。

解释一下吧：

既然print要实现迪米特，control也要实现迪米特，那么怎么同时输出也兼顾控制呢？

没错，还需要有个业务类，他的作用也十分单一——联合用户，输出，控制

在我的程序里是这个Bussness类。

这样就实现了迪米特。

长得帅长得漂亮的小伙伴都发现了，还有一个Main类和Driver类

他们是干什么的呢？

Driver是司机的实体类，是这个问题里隐藏的，是用户，使我们该思考的地方，它的存在是与Bussness类交互，使用Bussness来操作整个系统。

Main类。。。其实就是测试程序用的工具类。

 

第四次作业：

老规矩总结下，这一次我们学到了什么吧？

1.抽象类

2.继承

3.单例模式

 

一、抽象类

当你想表示一个类有着方法，但暂时不知道这个方法该如何实现时，你就会用到它，

关键字abstract

若一个类里有抽象方法时，那么这个类应该定义成abstract类

例如，这里有一个类，储存了一个图形的颜色，想要求它的面积，但是不知道他是什么形状

不知道用什么方法来求它的面积，那就可以使用抽象类

public abstract class Shape {
    String color;
    
    public Shape() {
    }
    
    public Shape(String color) {
        this.color = color;
    }
    abstract public double getarea();
}

 

 

二、继承

使用时在类后面注明继承哪一个类，extends XXX

当有些方法已有的时候，只需要在原有的代码上新增一些新的代码时，你就可以用到继承

当继承抽象类的时候，可以覆写里面的抽象方法，这个叫做实现；

覆写函数前加上@Override，既可以帮助我们查错，亦可以增加代码的可读性

 

几种继承模式：
1.整体->部分
2.大类->小类

 

尽量避免父类没有的方法而写在子类这种继承
里氏代换原则：
当B是A的子类时，
用类B的对象，代换成类A的对象，若成立，则是一个好的继承
说人话：子类的方法，父类要有。

 

还是这个例子

 

class Cricle extends Shape{

    private double radius = 0;
    
    public Circle() {
        
    }
    
    public Circle(String color,double radius) {
        super(color);
        this.radius = radius;
    }
    
    @Override
    public double getArea() {
        return radius*radius*Math.PI;
    }
}

 

三、单例模式

当你想要一个类只有一个对象，或者一个类生成的多个对象管理的东西是唯一的时，

可以试试这个。

关于单例模式如何实现，网上讲的比我详细，我再次不过多赘述。

 

第四次作业，实现单例模式。

 

 

在原来的东西没有变太多，类图上只是在类上面多了个指向自己的箭头。

 

 

 

 

第五次作业：

 

 

 多肽

当我输入一个命令，要控制一堆东西，每一个不同的东西接收到这个命令要作出自己不同的动作。

比如老师给的指令，出教室，那么一般都会找最近的出口，比如前面的同学走前门，后面的同学走后门。

那么这个就是多肽

怎么实现？

父类，写有一个方法（抽象的），子类来实现这个方法，每个不同的子类实现的方法不同。

还是那个例子，

Cricle类的getarea方法可以在子类定义

Triangle类的gtearea方法也可以在子类定义

那么两种覆写后的方法不一样，但在父类里都可以调用这个方法。

那么这个多肽就实现了。

那么这次作业就是实现多肽

 

 这就是我的类图

他实现了两个版本的雨刷控制

G1和G2拥有不同的雨刷速度

但是都是通过调用control类的同一个方法来控制雨刷，实现了多肽

好100分！【自嗨】

 

 

总结：

通过这个阶段的学习，我还有些经验想分享，

1.设计类的时候应该从基层开始思考，逐层向上，这样有助于我们梳理逻辑。

例如：当我要设计一个猪圈管理系统。那我第一个思考的问题是什么？

“应该用什么方法管理猪圈？”吗？

不，应该首先思考的是用户。“这个管理系统给谁用？”

答案很明显，是给人和猪用的。但是还应该详细一点，给养殖人员用，给老板用，给母猪用，给公猪用，等等等等。。

那么我该思考的第二个问题是什么？怎么管理吗？

“老板和养殖人员属于人的一端，公猪母猪属于猪的一端。”吗？

不，应该思考，这些用户需要实现什么功能。

比如，老板要用到的功能是，查看当日流水，养殖人员要用到，查看某只猪的状态，猪要用到，指引某只猪前往某个区域等。。

像这样，把所有最基础的根基稳固下来，往上需要思考的问题只会越来越少

 

像是一棵树，如果他的生长是从树干开始，分枝分叶，那我们的思考应该反过来，找到每一篇叶子，逐渐合拢，最后归并到树的主干。

 

2.写过的代码一定要分版本保存，TwT

你每一次修改代码前一定要保存好原来的代码，不然当你发现你修改后的还不如修改前的时，哭都来不及

TwT

 

七个原则总结：

有一些课上只是简单的提了一下，但还是记录了下来

所有原则，为开闭原则服务

原则一：单一功能原则

Single Responsibility Principle, SRP

核心思想：解耦和增强内聚性（高内聚，低耦合）

类被修改的几率很大，因此应该专注于单一的功能。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题

原则二：开闭原则

Open-Closed Principle, OCP

核心思想：对扩展开放，对修改关闭

扩展开放：模块添加新功能，不改变原有的代码

修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的

原则三：里氏替换原则

Liskov Substitution Principle, LSP

核心思想：任何父类出现的地方，子类都可以替代出现

原则四：依赖倒转原则

Dependence Inversion Principle, DIP

核心思想：要依赖于抽象，不要依赖于具体的实现

原则五：接口分离原则

Interface Segregation Principle, ISP

核心思想：不应该强迫客户程序依赖他们不需要使用的方法

一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口当中

原则六：合成复用原则

Composite Reuse Principle, CRP

核心思想：尽量使用对象组合，而不是继承来达到复用的目的

继承关系是强耦合，组合关系是低耦合

原则七：迪米特原则

Law of Demeter, LoD

又称最少知识原则

核心思想：一个对象应当对其他对象有尽可能少的了解,不和陌生人说话

降低各个对象之间的耦合，提高系统的可维护性

 

搜索

复制