Macros and Subroutines. When you use the same piece of code in two places, you convert that piece of code into a subroutine or macro, so that its body only needs to be written once. You use parameters to move data in and out of the subroutine or macro.

Extra Parameters. Sometimes you can merge two functions with similar parameter lists into one that takes an additional parameter to tell it which of the two original functions it is supposed to behave like.

Overloading. Whenever you have two functions with different parameters but the same name, you're using the same name because you believe the functions are similar in some way. This constitutes a generalization, even though in this case the computer doesn't really benefit from it.

Abstract Classes. Abstract classes isolate the common characteristics of their descendants.

Templates. Templates allow functions and classes to be parameterized by type.

Libraries. Placing a piece of code in a library allows it to be used by more than one program.

Here are some examples of inappropriate generalizations:

A function that is not clearly named - if you need to read the method to know what it does, it wants refactoring

A function parameter which is always given the same value

Overloaded functions that do not behave even conceptually similarly

An abstract class with only one descendant

A template which makes sense with only one type argument

A library which is used by only one program

It's interesting to note that all these maladies can be cured by refactoring. But refactoring isn't always possible, particularly when you're dealing with somebody else's immutable code. (Maybe the real problem is the immutability of the code, and not the generalization at all.)

Here are some times at which a programmer can generalize:

A programmer can generalize by refactoring, when the code he is generalizing is already in hand. This guarantees that the generalization will be useful - at the cost of doing without it until the code is already written!

A programmer can generalize when he knows he is going to need it. He may not have written the code yet, but he knows that he is going to, probably within the next few days. In this case, generalization now can be a big timesaver over refactoring later.

A programmer can generalize when he thinks, but is not sure, he is going to need it. This paves the way for a possibly inappropriate generalization. When the generalization turns out to be inappropriate, we call it premature - especially if it gets caught in a code freeze or an interface-to-the-code freeze. (But when it's appropriate, we call it foresight.)

A programmer can make superfluous generalizations when he clearly knows better, but usually this doesn't happen.

JobSecurity

Contributors: EdwardKiser

I would consider speculation as different from generalization. Until you have the information necessary, you are just guessing at what is needed and your success is determined largely by luck. I also believe you may be grossly underestimating the costs of speculation. -- WayneMack

                                                                                                                                   网站优化