2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 4, 2015
- Bits and Pieces
Reuse. This was the promise of object-oriented programming. Back in the early 1990’s we were told to move from C to C++ because it promoted reuse. That was wrong.
The way to reuse code is through delegation, by calling a piece of code. Delegation has been around since assembly language so OO languages didn’t introduce it. Being able to keep code and data together in objects does help make code more automatous but most people assumed that the reuse OO promoted was through inheritance.
Inheritance is a powerful feature in OO languages but inheritance has been heavily misused by developers. Inheritance is generally not the best way to promote code reuse. I have a lot more to say about that, which will have to wait for a future blog posts (or perhaps several blog posts.)
My rule of thumb for code reuse is if I have only one client who wants to consume my service then I’ll write the service for that one client. When I get a second client with similar needs then I’ll look for ways to promote reuse. Trying to anticipate what other clients need when I only have one client is inefficient and error-prone. Instead, code for what you need today and if tomorrow you discover you can use some of the pieces you already have then look for reuse. This keeps development focused on tangible results and is, in the long run, more efficient.
Previous Post: « What Makes a Good Test?
Next Post: Go Deep Rather than Wide »