Alan Shalloway is the founder and president of Net Objectives. Since 1981, it provides for object-oriented and software-oriented guidance and training, such as Attachmate, Avaya, Boeing, IBM, Microsoft, Phillips Medical Systems, Price Waterhouse Coops, QWest. Wait, ALAN's research includes: Design Patterns, Java, C , XML, XP and Agile Software Development. His book "Design Patterns Explained: A New Perspective On Object-Oriented Design" is about to be issued, by transparent (gigix) translation) is "design mode" John Vlissides is called the best Design mode entry book. Alan has a master's degree in computer science in MIT. The following is the exchange record. Translation from gigix.
Take one of the paragraphs
All articles http://tech.ccidnet.com/pub/disp/Article?columnid=292&articleid=24346&pageno=2
Zergo: Can you tell me some principles when designing objects? Shalloway: The object is a responsible thing. They are responsible for themselves. You are talking to them through interfaces. You only manage them "what to do", don't worry about them "how to do". YHUFO: The interface of the class is always more difficult to design. Can you tell me some skills for interface design? Shalloway: When you design the interface, don't just think about the situation in your hand, you still think that the current situation may change, this is very important. However, in order to maintain the agility of the development process, do not do unnecessary extensions on the interface when considering other situations. However, sometimes through the future needs, you can get a relatively universal solution. CHARITY_Zhou: How do you think about the relationship between the reuse and complexity in the software design? Shalloway: There is a bad tendency in object-oriented design: forced can be copied from the beginning. This is not a good idea, but we often do this. We have considerable emphasis when we design superclars, and then cover superclasses in subclasses when they need to change. The problem is that this often causes coupling between the unrelated concepts. For example, suppose you want to create a sales order system, you use superclars to express similar concepts (taxes, freight, etc. "fees") and then distinguish them in subclasses. As a result, you have a coupling between taxes and fees. This is not a problem in a period of time, but it will finally have problems. It will make your system difficult to understand. In programming, we need to pay attention to loose coupling (to avoid side effects) and high-polyset (in order to make code clearly), avoid redundancy (for efficiency). We are able to grasp the complexity of yourself - put them behind the interface or abstract class. For things that have emerged in the field, we should ask yourself: Is it a specific way to do something? Still do a universal method for a certain type? This book tells how we look for things that may change, how to pack changes: to find universal concepts, define the interface for the universal concept, let customers call the interface; for a particular method, implement the universal interface. GIGIX: I think the principle of object-oriented design (for example, open-closed principles) is more important than specific modes, is it? Shalloway: I agree. Mode is just a specific solution. However, XP believes: Do not manage OCP (open-closed principles). GIGIX:? If you don't follow the OCP, how to ensure the quality of the code? Shalloway: You can't write the code that never modify, and this is the target of OCP. However, please ask yourself, why should I avoid modifying the code? Of course, there will be a lot of reasons. For example, a lot of code is very fragile - if you have modified a place, it will destroy another place. However, if you think about reducing the degree of coupling of the code, then modifications will not cause side effects. You may find another reason: if I have modified the code, you must re-test. However, if you are ready for automation test, the price of the system test will not be very high. Software developers have circulated a statement: we have used a lot of time to fix the error. is it? How many people think so? Think about your hardest problem, the hardest mistake.
Now, think about how long you have used to find the error in your code? If the code structure is good, how much time can you save? How much is it to save? Anyway, most of the time is not consumed above. The wrong repair time is relatively small, and the time required to find errors is much more. GIGIX: Agree. SHALLOWAY: In the 1980s, I used half of the code time (10% of all times) to a system I wrote. At that time, my coding skills were still very immature, there are many coupling in the code, and the degree of cohesive is not good. This is a good experience. GIGIX: Then it is definitely difficult to maintain. Shalloway: right. If there is no strong internal gather, coupling is close, the test is small, so the system is really difficult to maintain. GIGIX: I have a problem. In OOD, which principles are most important? Shalloway: I can't say which principles are "most important", but I can list some important principles. You should regard the object as a definition of good responsibility; the object should be responsible for yourself; package is a form of hidden: hidden data, implementation or class; make the coupling between things (loose coupling); each method One thing, only one thing; class only contains related methods; avoid redundancy. Outmyth: How do I achieve this goal of "low coupling"? Shalloway: "Low Coupling" means that you have to define your interface: let the calling object you can send all the information you need for the service object. Private data and private methods may be helpful. Crystal_Y: Abstract, common / change point analysis, is these to get a loose core? Shalloway: These things can help you look at the problem in a better way. If you have programmed this, then you have much less. When designing interface, you only need to consider how to express the commonality between things. AgileMind: What is appropriate, loosely coupled design pattern, can you tell me? Shalloway: Loined things can change without causing side effects, nor does it cause many code modifications.
