Prefactoring By Ken Pugh

Just now i finished reading Prefactoring Book By Ken Pugh.

Nice book written by Ken Pugh.

I wanted to share few important points i found from this book.

1) Refactoring is the practice of altering code to improve its internal structure without changing its external behavior. Prefactoring uses the insights you have gleaned from your experience, as well as the experience of others, in developing software. The expertise gained in refactoring is part of that experience.

2) Separation of concerns deals with splitting responsibilities between different classes, different methods, and different variables.By separating a class into multiple classes, you allow for changes in one of the classes not to affect the other classes. If you change the GUI, for example, you do not have to change the business rules class. You might not necessarily want to split every one of your classes into as many classes as we do in the example system, but at least you should recognize that this is a possibility.

3) DON'T REINVENT THE WHEEL.
Look for existing solutions to problems before creating new solutions.

4) Create a clearly defined name for each concept in a system.

5) SPLITTERS CAN BE LUMPED MORE EASILY THAN LUMPERS CAN BE SPLIT.
It is easier to combine two concepts than it is to separate them.

6) CLUMP DATA SO THAT THERE IS LESS TO THINK ABOUT.
Clumping data cuts down on the number of concepts that have to be kept in mind.

7) MOST STRINGS ARE MORE THAN JUST A STRING.
Treat String as a primitive data type. Describe attributes with abstract data types, instead of as Strings.

8) NEVER LET A CONSTANT SLIP INTO CODE
Use a symbolic name for all values.

9) PROTOTYPES ARE WORTH A THOUSAND WORDS
A picture of an interface, such as a screen, can be more powerful than just a description.

10) Preconditions are assertions that must be true when the method is called so that the method can perform its operations. Postconditions are assertions that should be true when the method finishes.

11) CREATE INTERFACE CONTRACTS
Design with well-defined interfaces and enforce the contracts for those interfaces.

12) VALIDATE, VALIDATE, VALIDATE
At each interface, validate that the input matches the contract.

13) COMMUNICATE WITH YOUR CODE
Your code should communicate its purpose and intent.Readability of code is best verified when tested by two or three programmers who read the code and explain what it does to the actual coder.This is called code readability test.

14) EXPLICITNESS BEATS IMPLICITNESS
Being explicit reduces misinterpretation.

15) CONSISTENCY IS SIMPLICITY
A consistent approach to style and solutions can make code easier to maintain.

16) ADAPT A PREFACTORING ATTITUDE
Eliminate duplication before it occurs.

17) DON'T REPEAT YOURSELF (DRY)
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

18) DOCUMENT YOUR ASSUMPTIONS AND YOUR DECISIONS
Keep a journal for retrospectives.

19) DECIDE ON A STRATEGY TO DEAL WITH DEVIATIONS AND ERRORS
Determine for your system what deviations and errors are, and how to deal with both.

20) IF IT CAN'T BE TESTED, DON'T REQUIRE IT
Every functionality requirement, whether formally or informally stated, should have a test created for it. If you cannot test a requirement, there is no way to determine whether you have met it.

21) DON'T OVERCLASSIFY
Separate concepts into different classes based on behavior, not on data.

22) AVOID PREMATURE INHERITANCE
Inheritance needs time to evolve.As an alternative to inheritance, we can use delegation.

23) IF IT HAS COLLECTION OPERATIONS, MAKE IT A COLLECTION
Collections separate object usage from object storage and hide implementation of aggregate operations.

24)Highly cohesive, loosely coupled classes are a common goal for class design. A cohesive class encapsulates a single concept or idea. A loosely coupled class does not depend on the implementation of other classes.

25) Coupling measures how two classes interrelate. If two classes are coupled, a change in one class can force a change in the other class. There are three degrees of coupling : tight, common, and loose. Tight coupling means that a change in the implementation of one class forces a change in the implementation of the other. With common coupling, the second class uses the interface methods of the first class. If the implementation of the first class changes, the second class does not need to change. Loose coupling means that a class does not even rely on the interface of another class, only on its existence.

26) Three Laws of Objects

An object shall do what its methods say it does

An object shall do no harm

An object shall notify its user if it is unable to perform a requested operation

27) NEVER BE SILENT
If a method encounters an error, it should report it, not remain silent.[*]

28) PLACE METHODS IN CLASSES BASED ON WHAT THEY NEED
If a method does not require instance data, it should not be a member of the class. Conversely, if all that the method requires is the instance data, it should be a member of the class.

29) THINK INTERFACES, NOT INHERITANCE
Interfaces provide more fluidity in the relationships between classes.

30) DO A LITTLE JOB WELL AND YOU MAY BE CALLED UPON OFTEN
Methods and classes that perform specific jobs can be reused more often.

31) SEPARATE POLICY FROM IMPLEMENTATION
Keeping the "what" separated from the "how" makes the what more readable and maintainable.

32) OVERLOADING FUNCTIONS CAN BECOME OVERLOADING
By using unique names, functions can be more self-describing.

33) SEPARATE CONCERNS TO MAKE SMALLER CONCERNS
Split responsibilities among multiple methods and multiple classes to simplify each method and class.

34) FIGURE OUT HOW TO MIGRATE BEFORE YOU MIGRATE
Considering the migration path might help you discover additional considerations in other areas of the design.

35) PERFORM A RETROSPECTIVE AFTER EACH RELEASE
Examining your design and how you created it can help in the next release.

36) NOTHING IS PERFECT
There is usually a better solution, but you can stop with good enough.

37) DECOUPLE WITH ASSOCIATIONS
Association classes decouple the two classes being associated.

38) TEST THE INTERFACE, NOT THE IMPLEMENTATION
Use the contract of the interface to develop the functional tests, not the implementation behind it.

39) SPLIT INTERFACES
Split a single interface into multiple interfaces if multiple clients use different portions of the interface.

40) GET SOMETHING WORKING
Create something basic before adding refinements.

41) USE THE SAME LAYOUT TO GET THE SAME LAYOUT
Use templates or scripts for classes and methods to create consistent logic.

42) ADOPT AND ADAPT
Create the interface you desire and adapt the implementation to it.

43) DO A LITTLE AND PASS THE BUCK
Add proxies to interfaces to add functionality.

44) THE EASIEST CODE TO DEBUG IS THAT WHICH IS NOT WRITTEN
Never write functionality that already exists in usable form.

45) DON'T CHANGE WHAT IT IS
Create new terms rather than trying to apply new meanings to current terms.

46) CONSIDER FAILURE AN EXPECTATION, NOT AN EXCEPTION
Plan how operations should respond to failures.

47) BUSINESS RULES ARE A BUSINESS UNTO THEMSELVES
Keep business rules separate from other logic.

48) CONSIDER PRIVACY
Systems need to be designed with privacy in mind.

49) DON'T LET THE COLD AIR IN
With interfaces exposed to the outside world, ensure that input validation and logging occurs.

50) AVOID PREMATURE GENERALIZATION
Solve the specific problem before making the solution general.

51) Prefactoring is not just about static guidelines. It also is about learning from your own experience. Keeping a journal of why adherence to or disregard for a guideline worked or did not work in a particular situation will help you develop your own variations and additions.

Hope you have enjoy reading this wonderful book.

About The Author

KEN PUGH has extensive experience in the area of software analysis and design. He has worked on systems ranging from goat serum process control to financial analysis to noise recording to satellite tracking. His previous books were on C and Unix, and he is a former columnist for the C/C++ Users Journal. He has taught programming courses for Wellesley College and the University of Hawaii, as well as numerous corporate courses, and he frequently presents at national conferences. As an independent consultant for over 20 years, he has served clients from London to Sydney. As an expert witness, he has provided testimony in both civil suits and criminal cases.

When not computing, he enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail.