Experiment two Java object-oriented programming

Experiment two Java object-oriented programming experiment content 1. Initial mastery of unit testing and TDD2. Understand and master the object-oriented three elements: encapsulation, inheritance, polymorphism 3. Initial mastery of UML modeling 4. Familiar with the S.O.L.I.D principle 5. Understanding the design pattern of the experiment requirements 1. Students without Linux Foundation are advised to first learn the basic Linux Basics (new version), VIM Editor Course 2. Complete the experiment, write the experiment Report, the experiment report is published in the blog Garden in the blog, notice the experiment report focus is Run Results, encountered the problem(Tools find, install, use, program edit, Debug, run, etc.), Solutions(empty methods such as "Check Network", "Ask classmates", "reading" and so on are 0 points) and Analysis(What can be learned from it, what gains, lessons, etc.). The report can refer to the guidance of Fan Fei Dragon Teacher 3. Plagiarism is strictly forbidden, and the results of the experiment of the perpetrator are zero, and other punitive measures are added. 4. would you please be in the lab building first ? ~/Code directory with their own number to create a directory, code and UML diagram to be placed in this directory, no study number will require redo, and then follow the following steps to practice。

Experimental instrument:

Name	Model	Number
Pc	MacBook (Win7)	1
Virtual Linux Systems	Lab Building Virtual Machine	1

First, the experimental steps

(a) Unit testing

( 1 ) Three kinds of code: pseudo Code, product code, test code

Example: Needs: In a Myutil class to solve a percentile achievement into the "excellent, good, medium, pass, fail" five grade system performance function.

A. Pseudo Code

Percentile five-point system:

If the score is less than 60, turn into "fail"

If the score is between 60 and 70, turn into "pass"

If the score is between 70 and 80, turn into "medium"

If the score is between 80 and 90, turn into "good"

If the score is between 90 and 100, turn into "good"

Other, turn into "error

B. Product Code

c. Test Code

Run display success, description product code there is no error here

Test the general situation:

Run display success, general product Code no problem

To test for abnormal conditions:

To test the boundary value:

To run the display without considering the score 100, modify the product code:

Since this code is complete

( 2 ) TDD (test driven devlopment, testing- Driven Development ) : Write test code First, and then write the product Code development method

General steps:

• 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

Rewrite the example of percentile to five by TDD, and feel the benefits of having a test code

A. in the Eclipse in Click the File->new->java Project " Create a new Tdddemo of the Java Project

B. in the project name Tdddemo on Right-click on the popup menu and select " New->source Folder " Create a new test directory Test

c. in the Test Right-click on the directory and select " New->junit Test case " Create a new test case class myutiltest

d. in the test case class myutiltest in , enter the test code, such as

E. The Red fork indicates that the code has a syntax error because Myutil class is not yet established, the class Percentage2fivegrade method also does not exist;

Create a new Myutil class in the src directory of Tdddemo , creating Percentage2fivegrade method, the test code has no syntax errors;

Right-click on the myutiltest.java and select "Run as->junit Test , the effect

F. The test results showed a red stripe ( Red Bar ) , indicates that the test did not pass;

Modify the product code Myutil.java like, run the test code as in the previous step, show the green bar

The coding rhythm of the **TDD is:

• Add test code, JUnit appears red bar
• Modify the Product Code
• JUnit appears green bar, Task complete

G. use cases to increase test exception conditions testexception and the use cases for testing boundary conditions testboundary , the running test code appears red bar;

Modify the product code, and then run the test code to appear green bar

(ii) Object-oriented three elements

1 , abstract

(1) The abandonment of the appearance factors of things and the extraction of essential factors

(2) The abstract ability of "refine, simplifying, Youbiaojili and seeking for the same" determines programmer's program design ability

(3) Taking out the essential features of things and not considering their details for the time being

(4) Abstraction includes process abstraction and data abstraction

2 , encapsulation, inheritance and polymorphism

(1) Object-oriented three elements: encapsulation, inheritance, polymorphism.

(2) Object-oriented thinking involves all aspects of software development, such as object-oriented analysis (OOA), Object-oriented design (OOD), and object-oriented programming (OOP). OOA decomposes The system according to the abstract key problem domain and focuses on what. The main line that runs through OOA, Ood, and OOP is abstraction.

(3) Ood modeling will be modeled using the Graphical Modeling Language UML (Unified Modeling Language), UML is a common modeling language, experiment using Umbrello to model

(4) The result of Process abstraction is function, the result of data abstraction is abstract data type, data abstraction is the core and origin of OOP

(5) Encapsulation actually uses the method to hide the data of the class, control the user's modification to the class and the degree of accessing the data, which brings the advantages of modularization and information hiding, and the interface is the accurate description means of encapsulation.

To illustrate:

A.java uses classes for encapsulation, such as a dog class:

The B.dog class hides the attribute color by using class and access control, opening the interface SetColor (), GetColor (), bark (), and ToString. The Dog class is a module that we can use with the following code to test the code and run the results as follows

C. The class diagram in UML can be used to describe the class dog: Open the shell, enter Umbrello on the command line, open the UML modeling software Umbrello;

Click the class icon on the toolbar, then click in class Diagram, and a box will pop up to enter the class name dog;

Put the mouse on the dog class, right-click, select Properties, in the popup dialog box in the display to remove the public only option;

Put the mouse on the dog class, right-click, select New->attribute, in the Pop-up dialog box, fill in the Type,name, and choose visibility, get as dog class

* In UML, the property of a class can display its name, type, initialization value, and attributes can also display private,public,protected. The methods of the class can display their method names, parameters, return types, and the Private,public,protected property of the method.    Where: + represents public; #表示 protected;-represents private. Using UML allows us to not focus on the details

D. Creating cat classes and Animaltest classes in the Dog class

E.uml class diagrams to show static relationships between classes, the Animaltest class relies on the dog class and Cat class, and UML relies on a straight line with arrows

Corresponding Code:

Both the F.dog class and the cat class have the color attribute and the corresponding set and get methods, which violate the dry principle mentioned earlier, and we can solve this problem by inheriting the color attribute and the corresponding method into the parent class animal, as shown in the following UML figure:

(Note that the representation of inheritance in UML class diagrams is to refer to the parent class with a triangular line)

G. Further abstraction, abstract the bark () and Cat Class Meow () in the dog class into an abstract method shout (), which overrides this method in the dog class and Cat class, as shown in the following UML diagram:

(Note that the shout () method in the animal class in the UML class diagram is an abstract method, is italic, and the animal class is abstract and italic)

Corresponding Code:

(iii) Preliminary design pattern

1 , S.O.L.I.D Principles

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)

(1) OCP is the most important principle, the content of which 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 expansion and closed to modifications.

Based on the OCP, with object-oriented polymorphism (polymorphic), more flexibility in handling change embracing change, OCP can be implemented with abstraction and inheritance, interface-oriented programming

(2) The contents of the SRP are:

• There should never be + than one reason for a class to change
• Never have more than one reason to modify a class

(3) The LSP content is:

• Subtypes must is substitutable for their base types
• Functions that use pointers or references to base classes must is able to use objects of derived classes without knowing I T
• The subclass must be able to be used by its base class
• Using a pointer to a base class or a referenced function, you must be able to use it without knowing the specific derived class object type

(4) The contents of the ISP are:

• Clients should not being forced to depend upon interfaces the They do
• Customers should not rely on interfaces that they do not use

(5) The content of the dip is:

• The modules should not depend upon low level modules. Both should depend upon abstractions
• Abstractions should not depend upon details. Details should depend upon abstractions
• High-level modules should not be dependent on low-layer modules. Both should be dependent on the abstract
• Abstraction should not depend on detail. Details should depend on abstraction

2 , patterns and design patterns

A pattern is a customary solution (solution) for a particular problem (problem) under an external environment (context). The pattern must make the problem clear, explain why it is used to solve the problem, and under what circumstances it will not work. Each pattern can be reused because of its repeatability, has its own name, can be imparted, and can be transplanted into different scenarios. Patterns can be seen as expert solutions to a problem that can be reused.

There are many patterns in computer science:

grasp Mode

• Analysis Mode

• Software Architecture Patterns

• Design Patterns: Created, structured, behavioral

• Management mode: The manager Pool implementation mode

• Interface Design Interaction mode

• ...

One of the most important is design patterns

3 , design pattern Real example

(1) Design pattern provides a subsystem or component for refining a software system, or a diagram between them, which describes the public rendition structure of a communication component, which can solve a design problem in a particular context. Behind the design pattern is the principle of abstraction and solid.

There are four basic elements of the design pattern:

Pattern Name: Description mode, easy to communicate, archive

problem: Describes where to apply the pattern

Solution: Describes a design's constituent elements, not for special cases

consequence: The results and tradeoffs of applying this pattern (trade-offs)

(2) Learning the design pattern is to understand the design patterns may exist over-design problems and how to avoid it.

(3) There are many other object-oriented principles besides the solid principle. Such as:

• "Combinatorial substitution Inheritance": this is to say that relative to inheritance, more inclined to use the combination;
• "The Law of the Piper": This means "the less you know about other classes, the better";
• "Common closure principle": This means that "related classes should be packaged together";
• "Stable abstract principle": This means that "the more stable the class, the more it should be composed of abstract classes";

These principles are not isolated, but closely linked, followed by one principle and one or more principles, whereas a violation of one of these principles is likely to violate one or more of the other principles. Design patterns are the result of the application of these principles in some specific scenarios. Therefore, the design pattern can be regarded as "framework" and the Ood principle as "norm". In the process of learning the design pattern, we should constantly reflect on it, which embodies the principle of object-oriented design.

(iv) Practice

1. use TDD to design off to implement plural class Complex

(1) Pseudo-code:

Plural class Complex

The value of the plural =a+bi;
Plus = (A1+A2) + (B1+B2) I;
minus = (A1-A2) + (B1-B2) I;

(2) Product Code:

(3) Test code:

Second, summary

The experiment I did not very well completed, the previous several tasks although still can be relatively smooth to finish, but in the back of the programming problem appears to be powerless. Actually always want to learn Java, also know that programming this kind of thing is not to look at the video to see the book, overnight can learn, or to do more problems, more practice, in order to summarize lessons in practice, learning experience, hope that the future of Java learning can have a good breakthrough bar.

Experiment two Java object-oriented programming