CSC/ECE 517 Fall 2009/wiki2 7 co: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 3: Line 3:


   ''The best way to attack the essence of building software is not to build it at all.''
   ''The best way to attack the essence of building software is not to build it at all.''
         - [http://en.wikipedia.org/wiki/Fred_Brooks  Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month  The Mythical Man-Month]''-
         - [http://en.wikipedia.org/wiki/Fred_Brooks  Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month  The Mythical Man-Month]''


In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month  The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.
In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month  The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.
Line 85: Line 85:
=== Conclusion ===
=== Conclusion ===
blah!
blah!
=== References ===
* Brooks, Jr., F.P. ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month  The Mythical Man-Month]''. Boston, MA: Addison Wesley Longman, Inc., 1995.

Revision as of 21:57, 9 October 2009

Code Reuse Methods and Mechanisms

  The best way to attack the essence of building software is not to build it at all.
        - Fredrick P. Brooks, Jr.,The Mythical Man-Month

In his 1975 classic, The Mythical Man-Month, Fred Brooks claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.

This page will review some of the different techniques that are available for code reuse, and then a comparison of the techniques will be presented.

Code Reuse Through Direct Code Use

There are several classic code reuse mechanisms which work at the fundamental source code level. This section will discuss this class of mechanisms.

Cut & Paste

blah

Macros

blah

Includes

blah

Code Reuse through Subroutines

This section explores code reuse mechanisms that involve executing common blocks of code that can provide utility or common operations.

Gosub

blah

Procedures

blah

Functions

blah

Code Reuse through Extension

Many languages allow existing code to be reused through extensions that leave the original code unaltered. This section explores those mechanisms.

Methods

blah

Inheritance

blah

Polymorphism

blah

Generics

blah

Mixins/Modules

blah

Aspect

blah

Comparing the Various Mechanisms

Why Reuse Is Not Always Embraced

With all the various techniques available, code reuse is not universally embraced, either academically or commercially. What are the reasons for not reusing existing code?

  • Speed -
  • Lack of documentation -
  • Complexity -
  • Poor Design -
  • Licensing Issues -
  • Lack of Trust/Fear -

Conclusion

blah!

References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_7_co&oldid=24539"