Code Complete, Second Edition的笔记(9)

按有用程度 按页码先后 最新笔记

• 

  第233页

  GoneChaosGone (埋头做一只伪造猫)

  Nothing very exciting in chapter 7.8.9. Basically they are about how to write a good routine, defensive programming and using pseudocode in programming. A good routine is easy for other programmers to understand , read and debug.To achieve this you need a good name, limited parameters ( 7 ----- it is a magice number in this book)...What I thinking is forget about these rules, just ask your coll... (更多)

  Nothing very exciting in chapter 7.8.9. Basically they are about how to write a good routine, defensive programming and using pseudocode in programming.

  A good routine is easy for other programmers to understand , read and debug.To achieve this you need a good name, limited parameters ( 7 ----- it is a magice number in this book)...What I thinking is forget about these rules, just ask your colleagues to read part of your work, if he / she can understand that's enough.

  The need of defensive programming is due to nothing can be trusted, because everything can be wrong. Users randomly having a shit on your system, hackers hunting for their glories in your products, database sometimes working as slow as my granma and even youself cant help of make mistakes can explain why we have to do programming devensively. How? check the input, catch the proper exception you should catch, log the error.

  Pseudocode? Some general class diagram and very limited pseudocode do good job to me. Actually if your algorithum is not that hard or your biz logic is not that complicated ,save your time on pseudocode. and writie your test case instead (TDD or BDD whatever).

  (收起)

  2012-02-19 05:02:29   回应

  收藏

  推荐
• 

  第143页

  GoneChaosGone (埋头做一只伪造猫)

  How to define a good class interface? Two questions you need ask yourself before writing codes. Q1:Is this a "has a" Relationship Q2:Is this a "is a" Relationship I've read through many books tried to explain the OO thinking in different ways,and the most concise explanation is found in Chapter 6.3 of the book. I admitted sometimes I inherited a class just for its interfa... (更多)

  How to define a good class interface? Two questions you need ask yourself before writing codes.

  Q1:Is this a "has a" Relationship

  Q2:Is this a "is a" Relationship

  I've read through many books tried to explain the OO thinking in different ways,and the most concise explanation is found in Chapter 6.3 of the book.

  I admitted sometimes I inherited a class just for its interface which was wrong.

  For example there is class called Password

  Public Class Password{
  ......
  Public String EncryptString(string plainStr){
  ......
  }
  ......
  }
  

  then while creating another class Account, you just crossed the same routine existing in Class Password. You might do sth like

  Public Class Account:Password{
  ....
  }
  

  What's the error in this code snippet?

  Well, it is quite obviouly now, since I mentioned Q1 and Q2.

  Is the relationship between Password and Account "is a"? NO. Account will never be a kind of password. Thus we should not use inheritatance to get the "EncryptString".

  Any other errors?

  Sure. Why make the routine "EncryptString" as a publice interface?Doing so leaks unnecessary infomation to other class and break the consistence of the Class password's interface, which potentially causes tight coupling in future as well.

  A better way to design this? Please leave your thoughts. :)

  (收起)

  2012-02-19 04:10:37   回应

  收藏

  推荐
• 

  第141页

  GoneChaosGone (埋头做一只伪造猫)

  Encapusulation Avoid friend classes I have no real experience in C++, so just have no idea what a "friend class" is. Ref to wikipedia, A friend class in C++, can access the "private" and "protected" members of the class in which it is declared as a friend. On declaration of friend class all member function of the friend class become friend of the class in whic... (更多)

  Encapusulation Avoid friend classes

  I have no real experience in C++, so just have no idea what a "friend class" is.

  Ref to wikipedia, A friend class in C++, can access the "private" and "protected" members of the class in which it is declared as a friend. On declaration of friend class all member function of the friend class become friend of the class in which the friend class was declared. Friend status is not inherited; every friendship has to be explicitly declared. Friend classes can help in improving encapsulation if used wisely.

  But why I wont see it in a modern OO language like Java and C#?

  Let me clarify how the friend keyword undermines OOP.

  Private and protected variables and methods are perhaps one of the most important part of OOP. The idea that objects can hold data or logic that only they can use allows you to write your implementation of functionality independent of your environment - and that your environment cannot alter state information that it is not suited to handle. By using friend you are coupling two classes' implementations together - which is much worse then if you just coupled their interface. http://stackoverflow.com/questions/203616/why-does-c-sharp-not-provide-the-c-style-friend-keyword

  (收起)

  2012-02-05 23:24:41   回应

  收藏

  推荐
• 

  第143页

  GoneChaosGone (埋头做一只伪造猫)

  coupling goes hand in glove with abstraction adn encapsulation.Tight coupling occurs when an abstractions is leaky,or when encapsulation is broken.If a class offers an incomplete set of service ,other routines might find they need to read or write its internal data directly. That opens up the class ,making it a glass box instead of a black box, and it virtually eliminates the class' encapsulation.... (更多)

  coupling goes hand in glove with abstraction adn encapsulation.Tight coupling occurs when an abstractions is leaky,or when encapsulation is broken.If a class offers an incomplete set of service ,other routines might find they need to read or write its internal data directly. That opens up the class ,making it a glass box instead of a black box, and it virtually eliminates the class' encapsulation.

  I agree with the point here. But in my general pratice, especially against some colleagues' work, if a routine or attribute does not work as my expection, i will dive deep into the glass box if I can, to find out whether I am wrong or it is a bug. I wont go to my colleague's desk and tell him, "hi, your code is not written in a proper abstract way, please correct it." It is just rude, and will result in some issues in your relationship with your work mates. An alternative way is to do some explanation to some code but without naming the code's auther.

  Anyway, if someone in the work tell me my work is bad, i will happy to listen to his idea, but it just me. (收起)

  2012-02-05 22:59:41   回应

  收藏

  推荐
• 

  第26页

  GoneChaosGone (埋头做一只伪造猫)

  Steve is right, prerequisites is totally depending on your boss's mind, if he wants you begin code asap, then you have to find a way to pretend you've followed his very "correct" decision. (更多)

  Steve is right, prerequisites is totally depending on your boss's mind, if he wants you begin code asap, then you have to find a way to pretend you've followed his very "correct" decision. (收起)

  2012-01-20 06:32:10   回应

  收藏

  推荐
• 

  第21页

  GoneChaosGone (埋头做一只伪造猫)

  Meaphors are heurristics, so even using "Building Construction" is still weak. Because in today's "posh" agile way,everything is keeping changing. Software is delievered frequently (weeks instead of months). Cannot image constructors keep changing their work week by week in the reallife. Software development is a unique process, as no metaphor can be used to describe it. ... (更多)

  Meaphors are heurristics, so even using "Building Construction" is still weak.

  Because in today's "posh" agile way,everything is keeping changing. Software is delievered frequently (weeks instead of months). Cannot image constructors keep changing their work week by week in the reallife. Software development is a unique process, as no metaphor can be used to describe it.

  Metaphors are for rookie :)

  Experience is not the triky things learned from a IDE, a languge,a framework. It is kind of thing tell you how to make a right decistion to every job. (收起)

  2012-01-20 05:39:25   回应

  收藏

  推荐
• 

  第5页

  可爱的肖恩 (肖恩是只羊咩咩)

  软件的实现为什么重要？ 1、Construction is a large part of software development. 2、Construction is the central activity in software development. 3、With a focus on construction, the individual programmer's productivity can improve enormously. 4、Construction's product, the source code, is often the only accurate description of the software. 5、Construction is the only activity that's guar... (更多)

  软件的实现为什么重要？

  1、Construction is a large part of software development. 2、Construction is the central activity in software development. 3、With a focus on construction, the individual programmer's productivity can improve enormously. 4、Construction's product, the source code, is often the only accurate description of the software. 5、Construction is the only activity that's guaranteed to be done.

  (收起)

  2011-12-29 01:17:26   回应

  收藏

  推荐
• 

  Preface

  可爱的肖恩 (肖恩是只羊咩咩)

  MY PRIMARY CONCERN IN WRITING this book has been to narrow the gap between the knowledge of industry gurus and professors on the one hand and common commercial practice on the other. Many powerful programming techniques hide in journals and academic papers for years before trickling down to the programming public. Although leading-edge software-development practice has advanced rapidly in recen... (更多)

  MY PRIMARY CONCERN IN WRITING this book has been to narrow the gap between the knowledge of industry gurus and professors on the one hand and common commercial practice on the other. Many powerful programming techniques hide in journals and academic papers for years before trickling down to the programming public. Although leading-edge software-development practice has advanced rapidly in recent years, common practice hasn’t. Many programs are still buggy, late, and over budget, and many fail to satisfy the needs of their users. Researchers in both the software industry and academic settings have discovered effective practices that eliminate most of the programming problems that were prevalent in the nineties. Because these practices aren’t often reported outside the pages of highly specialized technical journals, however, most programming organizations aren’t yet using them in the nineties. Studies have found that it typically takes 5 to 15 years or more for a research development to make its way into commercial practice (Raghavan and Chand 1989, Rogers 1995, Parnas 1999). This handbook shortcuts the process, making key discoveries available to the average programmer now.

  (收起)

  2011-12-29 01:10:03   回应

  收藏

  推荐
• 

  第40页

  azalea (哀莫大于心死)

  Clients get excited when they think of a new feature. In their excitement, their blood thins and runs to their medulla oblongata and they become giddy, forgetting all the meetings you had to discuss requirements, the signing ceremony, and the completed requirements document. The easiest way to handle such feature-intoxicated people is to say, "Gee, that sounds like a great idea. Since it's no... (更多)

  Clients get excited when they think of a new feature. In their excitement, their blood thins and runs to their medulla oblongata and they become giddy, forgetting all the meetings you had to discuss requirements, the signing ceremony, and the completed requirements document. The easiest way to handle such feature-intoxicated people is to say, "Gee, that sounds like a great idea. Since it's not in the requirements document, I'll work up a revised schedule and cost estimate so that you can decide whether you want to do it now or later." the words "schedule" and "cost" are more sobering than coffe and a cold shower, and many "must haves" will quickly turn into "nice to haves". (收起)

  2011-12-10 11:44:04   回应

  收藏

  推荐