Java Experiment Two experiment report 20135108 Li Zeyuan

Beijing Institute of Electronic Technology (BESTI)

Lab Report

Course: Java class: 1351 Name: Li Zeyuan No.: 20135108

Score: Instructor: Lou Jia Peng Experimental Date: 2015.5.8

Experiment level: Preview degree: Experiment time: 15:30~18:00

Instrument Group: 27 Compulsory/elective: Elective experiment number: 02

Experiment Name: Java Object-oriented programming

Experimental purposes and requirements:

1. Initial mastery of unit testing and TDD

2. Understanding and mastering the object-oriented three elements: encapsulation, inheritance, polymorphism

3. Initial mastery of UML modeling

4. Familiarity with S.O.L.I.D principles

5. Understanding Design Patterns

Experimental instrument:

Name	Model	Number
Computer		1
Laboratory Building		1

Statistics for PSP (Personal software Process) time

Steps	Time-consuming (min)	Percentage
Demand analysis	15	7.5%
Design	40	20%
Code implementation	45	22.5%
Test	40	20%
Analysis Summary	60	30%

Experiment Content One:

(a) Unit testing

(1) Three kinds of code

What to do before programming, how to do to think clearly before you write the program and write well. To use the program to solve the problem, you will write three kinds of code:

• Pseudo code
• Product Code
• Test code

Now, let's use an example to illustrate how to write these three kinds of code.

Requirements: We want to solve a percentile grade in a Myutil class turn into "excellent, good, medium, pass, fail" five grade system performance function.

Pseudo code:

If the score is less than 60, fail

If the score is in 60~70, pass

If the score is 70~80, medium

If the score is 80~90, good

If the score is 90~100, good

Product Code:

Use Java to translate pseudo-code

Test code:

Used to test the product code.

Tried 50 of this number

But 50 is obviously not enough, the bottom of a number of test groups of data.

Test again-10 and 115 of this error data, found that the result of run-10 is incorrect

Modify Code

It's no problem to run the test again.

Test the boundary data again:

Found 100 wrong, and then modify the code

Test Pass

(2) TDD (test driven devlopment, testing-driven development)

Write the test code first, then write the product Code development method called "Test-driven Development" (TDD).

The general steps for TDD are as follows:

• Clear the current functionality to be completed and record it as a test list
• Quick completion of writing test cases for this feature
• Test code compilation does not pass (no product code)
• Write the Product Code
• Test Pass
• Refactor the code and ensure the test passes (refactoring the next lab session)
• Cycle through the development of all functions

Based on TDD, we do not have an over-design situation, and the requirements are expressed through test cases, and our product code is only allowed to pass the test.

Still take the above example as an example:

About the boundary test no longer one by one shows, adjust the product code to the content that can pass the test. As shown above.

(ii) Object-oriented three elements

(1) Abstract

Abstraction is a matter of extracting the essential features of things and not considering their details for the time being. For complex system problems, we can solve problems by means of hierarchical abstraction. At the highest level of abstraction, the solution of the problem is described in a generalized way, using the language of the problem environment. In the lower layers of abstraction, they are described in a procedural way. When describing a problem solution, use a problem-oriented and implementation-oriented terminology. In program design, abstraction consists of two aspects, one is process abstraction and the other is data abstraction.

(2) encapsulation, inheritance and polymorphism (three elements)

Encapsulation actually uses methods to hide the data of the class, controlling the user's modification of the class and the degree of access to the data, resulting in the benefits of modularity (modularity) and information hiding (information hiding) ; interface (interface) is an accurate description of the package.

Based on encapsulation, inheritance can implement code reuse , it should be noted that inheritance is more important to achieve polymorphism.

　　polymorphism refers to the phenomenon that different class objects will execute different code when they invoke the same signed member method. Polymorphism is the basis of the flexibility and extensibility of object-oriented programming .

(iii) Preliminary design pattern

Object-oriented three elements are "encapsulation, inheritance, polymorphism", and any object-oriented programming language will support these three elements syntactically. It is very difficult to use the three elements, especially polymorphism, with the help of abstract thinking, and the S.O.L.I.D design principle is a good guide:

• SRP (Single Responsibility Principle, sole responsibility principle)
• OCP (open-closed Principle, open-closed principle)
• LSP (Liskov substitusion Principle,liskov substitution principle)
• ISP (Interface segregation Principle, interface separation principle)
• DIP (Dependency inversion Principle, dependency inversion principle)

  OCP is one of the most important principles in Ood, and the OCP content is

  • Software entities (class, modules, function, etc) should open for extension,but closed for modification.
• • Software entities (classes, modules, functions, etc.) should be open to extensions and closed to modifications. The contents of the
  • SRP are:
  • there should never be greater than one reason for a class to change
  • never have more than one reason to modify a The contents of a class
  • LSP are:
  • subtypes must be substitutable for their base types
  • Functions this use pointe RS or references to base classes must is able to use objects of derived classes without knowing it
  • subclass must be available for its base class
  • Use a pointer to a base class or a referenced function, and you must be able to use it without knowing the specific derived class object type

  dip is:

  • High Level module s should not depend upon low level modules. Both should depend upon abstractions
  • abstractions should not depend upon details. Details should depend upon abstractions

  high-layer modules should not be dependent on low-level modules. Both should be dependent on the abstract

  (iv) exercises

• 1) Properties of the plural class ComplexNumber
  Realpart: Real part, representing the real portion of a complex number
  Imaginpart: Imaginary part, representing the imaginary part of a complex number
  2) method of complexnumber of plural class
  ComplexNumber () constructor, set the real part, the imaginary part to 0
  ComplexNumber (Double R, double i) constructor to create complex objects while completing real parts of complex numbers, initialization of imaginary parts
  Getrealpart () get the real part
  Getimaginarypart () Get imaginary part
  Getrealpart (double D) setting the real part
  Getimaginarypart (double D) Set imaginary part
  Add (ComplexNumber c) Complex sum
  Add (double c) Add complex number
  Minus (ComplexNumber c) Complex subtraction
  Minus (double c) subtraction of complex numbers
  Complexmulti (ComplexNumber c) Multiply plural
  Complexmulti (double c) multiplication of complex numbers
  ToString () combines the real part of the current complex object with the imaginary part into a a+bi string form

• The above is passed the test. But no print results, so I changed c.tostring () to System.out.println (C.tostring ());
• Also, the multiplication method was wrong and changed once.
• Also found that this is wrong, This.realpart executed the first sentence after the change, the result is not right behind, and then I used a middle variable
• But the result is right. Print out the +--number at the same time, I added a judgment to ToString
• Show the final result:
• Benefits of testing:
• Write the test code first, you can guide me to complete a class that can implement these functions, the whole class of the building will have a more full view of the concept.

Java Experiment Two experiment report 20135108 Li Zeyuan