CSC/ECE 517 Fall 2010/ch6 6f AZ: Difference between revisions
(→Origin) |
(→Origin) |
||
| Line 6: | Line 6: | ||
=Origin= | =Origin= | ||
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was making it near impossible to continue development, so they hired Robert to help them out. | The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was making it near impossible to continue development, so they hired Robert to help them out. | ||
The issue with their code was that there was one main Job class that was used by almost all of the tasks. Anytime a print job or a stapling had to be done, a call was made to some method in the Job class. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. This meant that a staple job would know about all the methods of the print job, even though the staple class had no use for them. The clients were being forced to depend on methods they did not use. When a developer had to change a small detail about a print job, every one of the classes that used the Job class would have to be recompiled. | The issue with their code was that there was one main Job class that was used by almost all of the tasks. Anytime a print job or a stapling had to be done, a call was made to some method in the Job class. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. This meant that a staple job would know about all the methods of the print job, even though the staple class had no use for them. The clients were being forced to depend on methods they did not use. When a developer had to change a small detail about a print job, every one of the classes that used the Job class would have to be recompiled. | ||
The solution suggested by Robert has now become the Interface Segregation Principle. He suggested that they add a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. Ergo, there was an interface created for each job, and the Job class would inherit from all of these interfaces. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about. Thus if a developer made a change to the Print Job, the Staple Job would be unaffected and have no need to recompile. | The solution suggested by Robert has now become the Interface Segregation Principle. He suggested that they add a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. Ergo, there was an interface created for each job, and the Job class would inherit from all of these interfaces. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about. Thus if a developer made a change to the Print Job, the Staple Job would be unaffected and have no need to recompile. | ||
Revision as of 13:49, 15 November 2010
Introduction
Interface Segregation Principle(ISP) states that "Clients should not be forced to depend upon interfaces that they do not use". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.
If followed, the ISP will help a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called SOLID. This helps in low coupling and high cohesion.
Origin
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was making it near impossible to continue development, so they hired Robert to help them out.
The issue with their code was that there was one main Job class that was used by almost all of the tasks. Anytime a print job or a stapling had to be done, a call was made to some method in the Job class. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. This meant that a staple job would know about all the methods of the print job, even though the staple class had no use for them. The clients were being forced to depend on methods they did not use. When a developer had to change a small detail about a print job, every one of the classes that used the Job class would have to be recompiled.
The solution suggested by Robert has now become the Interface Segregation Principle. He suggested that they add a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. Ergo, there was an interface created for each job, and the Job class would inherit from all of these interfaces. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about. Thus if a developer made a change to the Print Job, the Staple Job would be unaffected and have no need to recompile.