Agile Software Development Study Note 3

1. If a class has too many responsibilities, these responsibilities are coupled. Changes in one role may weaken or suppress this class's ability to fulfill other responsibilities. This coupling will put the fragile (fragile) design upside down, and when changes occur, the design will suffer unexpected damages. P88

 

2. In SRP, we define the responsibility as a reson for change ). P89

 

3. The changed axis is meaningful only when the change actually occurs. If there is no indication, it is unwise to apply SRP or any other principle. P90

 

4. Any system changes in its lifecycle. If we expect that the system will not be discarded after version 1st, we must keep this in mind. P92

 

5. How can I change the module's source code without modifying it? How can we change its functions without modifying the module? P93

Answer: The Key is abstraction (or interface ).

 

6. Since it is impossible to completely close the issue, it is necessary to treat it with a policy. That is to say, the designer must make a choice for the change closure of the module designed by him. He must first guess the most likely types of changes, and then construct an abstraction to isolate those changes. P97

 

7. This is not easy to achieve. Because it means you need to guess the changes that may occur during the growth of those applications based on experience. If the developer guessed it was correct, they would be successful. If they guess wrong, they will suffer. And in most cases, they will guess wrong. P98

 

8. OCP compliance is expensive. It takes time and effort to create a correct abstraction. At the same time, those abstractions also increase the complexity of software design. The number of abstractions that developers can process is limited. Obviously, we want to limit the OCP application to possible changes. P98

 

9. I don't want the design to carry many unnecessary abstractions. Generally, we prefer to wait until we actually need those abstractions before placing them in. P98

 

10. In order to prevent unnecessary complexity from being carried by software, we will allow ourselves to be fooled once. This means that when we first write the code, we assume that the change will not happen. When a change occurs, we create an abstraction to isolate similar changes that occur later. In short, we are willing to be hit by the first bullet, and then we will ensure that we are no longer hit by any other bullet from the same gun. P98

 

11. stimulate changes-if we decide to accept the first bullet, the sooner and faster the bullet arrives, the more favorable it will be for me. We hope to know the possible changes shortly after the development work starts. The longer it takes to identify possible changes, the more difficult it is to create a correct abstraction. P98

 

12. In many aspects, OCP is the core of object-oriented design. Following this principle can bring about the great benefits that object-oriented technology claims (that is, flexibility, reusability, and maintainability ). However, it does not mean that we follow this principle as long as we use an object-oriented language. It is also not a good idea to abstract every part of an application. The correct approach is that developers should only abstract those parts that present frequent changes in the program. Rejecting immature abstractions is just as important as abstraction itself. P101

 

13. If a model is isolated, it is not really effective. The validity of the model can only be expressed through its customer program. P107

 

14. Who knows what reasonable assumptions the design user will make? Most of these assumptions are hard to predict. In fact, if we try to predict all these assumptions, the system we get is likely to be filled with the smell of unnecessary complexity. Therefore, like all other principles, the best way to do this is to only predict the most obvious violations of LSP and postpone all other predictions until the associated vulnerability smells bad, to process them. P107

 

15. The term "IS-A" is so broad that it cannot be defined as a child type. The correct definition of the child type is "Replaceable". Here, the replaceable type can be defined through display or implicit contract. P115