Specification 3_PHP Tutorial

Directory Document All directories need to have a README document, which includes: The function of the directory and its contents An online description of each file (with a link). Each description should usually also extract some attributes of the file header. name. Includes setup and usage instructions to guide people on how to connect to related resources: Source file index Online documentation Paper documentation Design documentation Other things that may be helpful to readers Consider this, when each of the original engineering staff left and came within 6 months A new person, the lonely and frightened explorer, should be able to traverse the entire project by using the source code directory tree of the entire project, reading the documentation, the header descriptions of the source files, etc. as a map.-------------------------------------------------------------------------------- Use a Design Notation and Process Programmers need to have a common language for talking about coding, designs, and the software process in general. This is critical to project success. Any project brings together people of widely varying skills, knowledge, and experience. Even if everyone on a project is a genius you will still fail because people will endlessly talk past each other because there is no common language and processes binding the project together. All youll get is massive fights, burnout, and little progress. If you send your group to training they may not come back seasoned experts but at least your group will all be on the same page; a team. There are many popular methodologies out there. The point is to do some research, pick a method, train your people on it, and use it. Take a look at the top of this page for links to various methodologies. You may find the CRC (class responsibility cards) approach to teasing out a design useful. Many others have. It is an informal approach encouraging team cooperation and focusing on objects doing things rather than objects having attributes. Theres even a whole book on it: Using CRC Cards by Nancy M. Wilkinson. -------------------------------------------------------------------------------- Using Use Cases A use case is a generic description of an entire transaction involving several objects. A use case can also describe the behaviour of a set of objects, such as an organization. A use case model thus presents a collection of use cases and is typically used to specify the behavior of a whole application system together with one or more external actors that interact with the system. An individual use case may have a name (although it is typically not a simple name). Its meaning is often written as an informal text description of the external actors and the sequences of events between objects that make up the transaction. Use cases can include other use cases as part of their behaviour. Requirements Capture Use cases attempt to capture the requirements for a system in an understandable form. The idea is by running through a set of use case we can verify that the system is doing what it should be doing. Have as many use cases as needed to describe what a system needs to accomplish. The Process Start by understanding the system you are trying to build. Create a set of use cases describing how the system is to be used by all its different audiences. Create a class and object model for the system. Run through all the use cases to make sure your model can handle all the cases. Update your model and create new use cases as necessary. -------------------------------------------------------------------------------- Open/Closed Principle The Open/Closed principle states a class must be open and closed where: open means a class has the ability to be extended. closed means a class is closed for modifications other than extension. The idea is once a class has been approved for use having gone through code reviews, unit tests, and other qualifying procedures, you dont want to change the class very much, just extend it. The Open/Closed principle is a pitch for stability. A system is extended by adding new code not by changing already working code. Programmers often dont feel comfortable changing old code because it works! This principle just gives you an academic sounding justification for your fears :-) In practice the Open/Closed principle simply means making good use of our old friends abstraction and polymorphism. Abstraction to factor out common processes and ideas. Inheritance to create an interface that must be adhered to by derived classes. -------------------------------------------------------------------------------- Design by Contract The idea of design by contract is strongly related to LSP . A contract is a formal statement of what to expect from another party. In this case the contract is between pieces of code. An object and/or method states that it does X and you are supposed to believe it. For example, when you ask an object for its volume thats what you should get. And because volume is a verifiable attribute of a thing you could run a series of checks to verify volume is correct, that is, it satisfies its contract. The contract is enforced in languages like Eiffel by pre and post condition statements that are actually part of the language. In other languages a bit of faith is needed. Design by contract when coupled with language based verification mechanisms is a very powerful idea. It makes programming more like assembling specd parts. -------------------------------------------------------------------------------- 其他杂项 这一部分包含着各种各样的该做的和不该做的。 在需要用到离散的数值使，不要使用浮点数变量。采用浮点数来做循环计数器无异于向自己的脚 开枪。Always use when testing floating point numbers, never = or => . Do not use automatic program beautifiers. The main people who benefit from good program styles are programmers themselves, especially programmers who have just started coding and algorithm design. Using automatic program beautifiers can only correct programs based on syntax, so It is impossible to do when there is a great need for attention to whitespace and indentation. Normal programmers who pay attention to details can very well use clear and intuitive styles to complete a function or file (in other words, some intuitive styles are stipulations of intention rather than wisdom that the program's automatic beautifier can read. ). Sloppy programmers should learn from careful programmers and not rely on automatic program beautifiers to increase program readability. The original beautifiers were programs that had to analyze the source code. Complex beautifiers were not worth the benefits, and beautifiers were best used to generate code in a machine-generated format. Accidental omission of the second = in a logical expression is a problem. The following is confusing and more like an error: if ($abool= $bbool) { ... } Did the programmer really want to assign a value here? Usually it is, but usually it is not. How to avoid causing such confusion? The solution is not to do this, use explicit and implicit judgment testing, the recommended method is to do the assignment before testing: $abool= $bbool; if ($abool) { ... } ----- -------------------------------------------------- -------------------------- Use if (0) to comment external code blocks Sometimes you need to comment a large section of test code. The easiest way is to use if (0) block: function example() { great looking code if (0) { lots of code } more code } You cannot use /**/, because comments cannot be included inside comments, but comments can be included in large sections of the program , isn’t it? -------------------------------------------------- ------------------------------- Different Accessor Styles Why Accessors? Access methods provide access to the physical or logical attributes of an object. We disallow direct access to attributes to break dependencies, the reason we do most things. Directly accessing an attribute exposes implementation details about the object. To see why ask yourself: What if the object decided to provide the attribute in a way other than physical containment ? What if it had to do a database lookup for the attribute? What if a different object now contained the attribute? If any of the above changed code would break. An object makes a contract with the user to provide access to a particular attribute; it should not promise how it gets those attributes. Accessing a physical attribute makes such a promise. Implementing Accessors There are three major idioms for creating accessors. Get/Set class X { function GetAge() { return $this->mAge; } function SetAge($age) { $mAge= $age; } var $mAge; } One Method Name class X { function Age() { return $mAge; } function Age($age) { $mAge= $age; } var $ mAge; } Similar to Get/Set but cleaner. Use this approach when not using the Attributes as Objects approach. Attributes as Objects class X { function Age() { return $mAge; } function rAge() { return &$mAge; } function Name() { return mName; } function rN

http://www.bkjia.com/PHPjc/532253.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/532253.htmlTechArticleDirectory Documents All directories need to have README documents, including: The functions of this directory and its contents a Online description of each file (with link), each description...