interface-oriented Programming (II)--programming example-T2?? s Notebook-Blog Park

Source: Internet
Author: User
Tags define abstract
interface-oriented programming (II.)--programming example This series of "interface-oriented programming detailed" will be divided into three parts:
An explanation of interface-oriented programming (i)--Thought Basics (published)
In this article, the interface and interface-oriented programming will be a general introduction, focusing on the explanation of the mind.
An explanation of interface-oriented programming (II.)--programming instance (published)
This article will combine an example of "Mobile storage device emulation" to give you an intuitive impression of interface-oriented programming.
An explanation of interface-oriented programming (III.)--Pattern Research (published)
Explains the interface-oriented ideas in several design patterns and based on. NET platform in the layered architecture of the interface-oriented thinking, deepen understanding.

Through the discussion of the previous article, I would like to have a general understanding of "interface Programming" by your friends. So in this article, we use an example to give you an intuitive impression of this important programming idea. For the full consideration of beginners, so this example is very simple, hope you master forgive me.

The question of the proposed



Definition:Now we want to develop an application to simulate the reading and writing of mobile storage devices, that is, computer and USB disk, MP3, mobile hard disk and other devices for data exchange.
Context (Environment):Known to implement U disk, MP3 player, mobile hard disk three kinds of mobile storage devices, requiring the computer to be able to exchange data with these three devices, and there may be new Third-party mobile storage devices, so the computer must be extensible, with the current unknown and possible future storage devices for data exchange.
Each storage device to read and write the implementation of different methods, U disk and mobile hard disk only these two methods, Mp3player also has a Playmusic method.
noun definition:Data interchange ={read, write}

See the above problem, I think you must have a lot of ideas in mind, this is a very good solution to the problem, many programs can achieve results. Below, I list a few typical scenarios.

Solution Listing


programme I:Define FlashDisk, Mp3player, mobileharddisk three classes, respectively, to implement the Read and write methods. The above three classes are then instantiated in the computer class, and each class is read and written separately. For example, write Readfromflashdisk, Writetoflashdisk two methods for FlashDisk. A total of six methods.
Programme II:Define abstract class Mobilestorage, write virtual methods inside read and write, three storage devices inherit this abstract class, and rewrite the read and write methods. The Computer class contains a member variable of type Mobilestorage and writes get/set for it, so that only two methods are required in computer: ReadData and WriteData, and the reading and writing of different mobile devices is achieved through polymorphism.
Programme III:Basically the same as scenario two, just do not define abstract classes, but define interface Imobilestorage, mobile storage classes implement this interface. In computer, polymorphism is realized through dependency interface imobilestorage.
Programme IV:Define interfaces Ireadable and iwritable, two interfaces contain only read and write, and then define interfaces Imobilestorage interfaces to inherit from Ireadable and Iwritable, with the remaining implementations being the same as scenario three.

Below, we analyze the above four kinds of scenarios:
First, one of the most straightforward scenarios is the simplest, but it has a fatal weakness: scalability is poor. Alternatively, it does not conform to the "open-close principle" (Note: The extension is open to the modification and closed). Computer must be modified when there is a third party extended mobile storage device in the future. This is like on a real computer, for each mobile storage device to implement a different socket, and each has its own driver. When we have a new mobile storage device, we have to unload the computer into eight blocks, then add a new socket and write a set of drivers for this new device. This design is clearly undesirable.
Another drawback of this scenario is that there are more redundant code. If there are 100 kinds of mobile storage, it is not acceptable to write at least 200 methods in our computer.

Let's take another look at Programme II and Programme III, these two scenarios are discussed together because they are basically a program (from the ideological level), but the means of implementation are different, one is to use an abstract class, one is to use the interface, and ultimately achieve the same goal should be the same.
Let's first evaluate this scenario: First, it solves the problem of code redundancy, because mobile devices can be replaced dynamically and common interfaces are implemented, so no matter how many mobile devices there are, as long as a read method and a write method are available, polymorphism helps us solve the problem. For the first problem, because the runtime can be dynamically replaced without having to hard-code the mobile storage class in computer, there is a new third-party device that can be completely replaced and run. This is called "dependency interface, not dependency with concrete class", do not believe you see, the Computer class has only one mobilestorage type or imobilestorage type member variable, as to what the specific type of the variable, it does not know, It depends on what we assign to the variable at run time. As a result, the coupling of computer and mobile memory classes is greatly reduced.
So here's the abstract class or the interface. Remember the first article I suggested for an abstract class and interface selection? Look at the motive. Here, our motivation is obviously to achieve polymorphism rather than code reuse, so of course we have to use interfaces.

Finally, let's take a look at scenario four, which is similar to scenario three, by abstracting "readable" and "writable" two rules into interfaces, and then letting Imobilestorage inherit them. In doing so, there is clearly a further increase in flexibility, but is there any suspicion of excessive design? My point is: This depends on the specific situation. If there are classes in our application that only implement read methods or implement write methods, such as CD-ROM, then this is also possible. If we know that later things are readable and writable, then the two interfaces are unnecessary. In fact, if you leave the Write method of a read-only device blank or throw an exception, you may not want the two interfaces. In a word: Theory is dead, people are alive, everything from the actual need to prevent design deficiencies, but also to prevent excessive design.
Here, we assume that future mobile storage is readable and writable, so we choose option three.

Implement


Below, we will implement the solution. My choice of language is C #, but I don't use C # 's unique properties in my code, so I can refer to friends in other languages as well.

First write the Imobilestorage interface:

1 namespace Interfaceexample
2 {
3 Public Interface Imobilestorage
4 {
5 void Read ()/read data from self
6 void Write ()//write data to itself
7}
8}
Relatively simple, there are only two methods, there is nothing to say, the next is the three mobile storage device specific implementation code:
U disk

1 namespace Interfaceexample
2 {
3 public class Flashdisk:imobilestorage
4 {
5 public void Read ()
6 {
7 Console.WriteLine ("Reading from FlashDisk ...");
8 Console.WriteLine ("Read finished!");
9}
10
One public void Write ()
12 {
Console.WriteLine ("Writing to FlashDisk ...");
Console.WriteLine ("Write finished!");
15}
16}
17}
MP3

1 namespace Interfaceexample
2 {
3 public class Mp3player:imobilestorage
4 {
5 public void Read ()
6 {
7 Console.WriteLine ("Reading from Mp3player ...");
8 Console.WriteLine ("Read finished!");
9}
10
One public void Write ()
12 {
Console.WriteLine ("

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.