Serial Java Programming (---) task-driven approach: Payroll settlement system

Task: or in the company, the company divides it into three categories of people: Department manager, sales clerk. In the payroll, the department manager took a fixed monthly salary of 8000 yuan. Technicians receive their monthly salary at $100 per hour. Sales staff according to 500 yuan base salary plus the monthly sales of 4% Commission. Design and implement a payroll settlement system.

Analysis: Whether the department manager, technician or salesperson has the common characteristics of employees. Be able to design an employee class (employee) first. And the method of settling wages is designed as an abstract method, because different employees have different ways of settling wages, need to carry out multi-state implementation. The so-called abstract method is a method that has no method body and is modified by the abstract modifier. Assuming that there is an abstract method in a class, this class is declared as an abstract class. An abstract class cannot be instantiated, which means that an object of an abstract class cannot be created. Next, you can derive the manager class (manager), the Technician Class (technician), and the Salesperson Class (salesman) on the basis of the employee class, which will override the abstract method in the Employee Class (override) and give the implementation of the method of settling the wages in the three class. This process is called inheritance (inheritance), which is one of the three main pillars of object-oriented programming. Next, when a payroll settlement is required. The ability to assign all employee objects to a reference to the employee type (because both a department manager, a technician, and a salesperson are employees, a reference to a parent type can refer to an object of the subtype, which is a type conversion that is not mandatory on the previous transformation). Again, the same reference is used to call the same method of settling the wages. So the same reference calls the same method but does something different (the way each employee settles the pay), which is the object-oriented thing-polymorphism (polymorphism), which together with encapsulation (encapsulation) and inheritance constitute the three main pillars of object-oriented.

The following is a UML class diagram of the system.

UML (Unified Modeling Language) is called Unified Modeling Language. UML is an open approach for explaining, visualizing, building, and writing a development approach to an object-oriented, software-dense system of artifacts. UML presents a series of best practices for project, which are on a large scale. The modeling aspects of complex systems, especially at the software architecture level, have been proven effective.

Simply put, UML is a graphical language that provides the standard notation for drawing software project drawings.

The diagram above is a class diagram in UML that describes the classes in the system and the relationship between classes and class, with the hollow triangular arrows representing the inheritance relationship. The relationship between classes and classes, in addition to inheritance (is-a relationships), has associations (has-a relationships) and dependencies (use-a relationships).

The code for the system looks like the following:

Employee.java

Package com.lovo.salsys;/** * Employee class * @author Shanhao */public abstract class Employee {private String name;//Name/** * constructor * @pa RAM Name Employee Name */public employee (String name) {this.name = name;}  /** * Settlement Salary * @return month monthly */public abstract double getsalary ()/** * Get Employee Name * @return name */public String getName () {return Name;} @Overridepublic String toString () {return name;}}

Manager.java

Package com.lovo.salsys;/** * Department Manager class * @author Shanhao */public class Manager extends Employee {public Manager (String name) {sup ER (name);} Public double getsalary () {return 8000.0;} Public String toString () {return "[Department manager]" + super.tostring ();}}

Technician.java

Package com.lovo.salsys;/** * Technical class * @author Shanhao */public class Technician extends Employee {private int workinghour;//working Between public technician (String name) {super (name);} public void Setworkinghour (int workinghour) {this.workinghour = Workinghour;} Public double getsalary () {return * workinghour;} Public String toString () {return ' [technical] ' + super.tostring ();}}

Salesman.java

Package com.lovo.salsys;/** * Salesperson class * @author Shanhao */public class salesman extends Employee {private double sales;//sales Publi C salesman (String name) {super (name);} public void Setsales (double sales) {this.sales = sales;} Public double getsalary () {return + sales * 0.04;} Public String toString () {return ' [Salesperson] ' + super.tostring ();}}

The following is the implementation procedure of the Payroll settlement system Salarysystemrunner.java

Package Com.lovo.salsys;import Java.util.scanner;class Salarysystemrunner {public static void main (string[] args) { Scanner sc = new Scanner (system.in); String[] names = {"Zhang Fei", "Guan Yu", "Ma Chao", "Jack Huang", "Zhao Yun"};  employee[] Emps = new Employee[names.length];for (int i = 0; i < emps.length; i++) {int emptype = (int) (Math.random () *  3); switch (emptype) {case 0:emps[i] = new Manager (names[i]); break;case 1:emps[i] = new Technician (names[i]); break;case 2:emps[i] = new salesman (Names[i]); break;} System.out.println (Emps[i]);} for (Employee e:emps) {if (e instanceof technician) {System.out.print ("Please enter" + e.getname () + "Working time of the Month:");((technician) e). Setworkinghour (Sc.nextint ());} else if (e instanceof salesman) {System.out.print ("Please enter" + e.getname () + "Sales for the Month:");((salesman) e). Setsales (sc.nextdouble ());} System.out.println (E.getname () + "salary for this month: $" + e.getsalary ());} Sc.close ();}}

Here, we are able to define a more tall state for the polymorphic. In fact. An instance method in a class is a service that an object can provide to the outside world, assuming that it understands polymorphism at the point of view of the service, and can interpret polymorphism as follows: When a system visits the services provided by System B, System B has many ways of providing services, but it is transparent to a system. In the example above, a system is the implementation of the payroll system, B system is the employee system, the employee system of the settlement of wages is the B system to a system to provide services. Each employee settles the pay differently, but the a system only knows how the employee can settle the pay. It is not understood that department managers, technicians and salespeople in B systems make different implementations of this method (Polymorphic implementations), so these are transparent to a system (invisible).

There are two key points to implementing polymorphism: Method Overrides (subclasses override parent class methods during inheritance) and object styling (assigning subclass objects to parent class references). In fact, there are two important principles of object-oriented program design. One is the principle of dependence reversal (Dependency inversion Principle), and the second is the principle of substitution of the Richter scale (Liskov Substitution Principal). The dependency reversal principle is about programming for the interface, not for implementation. In detail, when defining a method's parameter type, the return type of the method, and the reference type of the object, an abstract type is used whenever possible with an abstract type. In the example above, we will define the object's reference type as an abstract type in an array of employee types, for each of the different types of worker objects. The principle of substitution on the Richter scale is that you can replace a parent object with a subclass object whenever you like. In other words, a subtype can be used where the parent type is used. This assumes that the parameter of a method is a parent type object. No matter what type of subtype is passed in to it. Suppose a subclass gives a different implementation version number to a method in the parent class. That would show polymorphic behavior when calling the method with a reference to the parent type. For the same reason, suppose that the return type of a method is a parent type. It is possible to return the parent type regardless of the subtype object in the method, in which case we can write a factory method when creating the object, thus creating a different subclass object, which is the GOF static design mode Factory mode. Let's explain this design through an example in the next chapter.

Copyright notice: This article blog original articles, blogs, without consent, may not be reproduced.

[Serial]java Program Design]---task-driven approach: Payroll billing system