The episode 1--in the development of hotel management system what is an object

-->
-->

After the "Hotel management system use case process Analysis" is completed, heart is really a little uneasy, because I really do not know what to rewrite next, according to their own reasoning to the topic defined as "the hotel management system of the class overview", to Csdn looked at the previous chapter, sure enough out of the question, Two colleagues gave the following reply:

Tobato (2003-7-16-20:41:55)

In a word, look carefully, the use case is written as if there is a problem. ^O^

Tobato (2003-7-16-20:39:26)

Oh, use cases can be said to have nothing to do with OO. Use use cases to better understand the problem you are trying to solve. But the way to solve this problem is to use OO or oo.

Dove_young (2003-7-16-16:05:24)

Also, I can't help but remind you: so far, your things and OO have not touched the edge. Problem definition, process analysis, these things can serve both oo and non-oo.

Dove_young (2003-7-16-16:02:33)

Having finished the use-case process analysis, I found myself in a dilemma because I had no idea what the use-case phrase meant. Don't be so dramatic, are you? You're going to scare the kids. Dizzy Ah ...

Sure enough, rookie is rookie, but I still want to make a statement, this is my first real design a thing, and I am not trained, the content is the fact, not to attract attention and pretend psycho. The concept of use cases is really just touching. It can be said that everything about design is the first contact. So there is absolutely no fear of scaring the children, and I sincerely hope that I can learn something from this series, the best other people can also learned something. So I have to stick to it before I reach the cliff, and I hope that peers who have a deeper understanding of the program can give more pointers. Thank you, everyone.

Before we get to the point, I'll take a look at the last mentioned "building user interfaces for object-oriented systems" (http://www.javaworld.com/javaworld/ jw-07-1999/jw-07-toolbox.html) has given me a lot of puzzles and questions.

The first confusion is that Allen Holub (author of "Building user interfaces for object-oriented systems" and "OO design process") puts it very emphatically: we are doing OO design, not CB ( class-based) Design (We ' re doing-object-oriented, not class-based designs). The title of the next section was supposed to be "an overview of the classes in the hotel management system", which now appears to be "an overview of the objects in the hotel management system". It may seem irrelevant, but now that Allen Holub it clearly, I think he has his own meaning (and rightly so) that the methods used in Delphi programming in the past are mostly class methods and static methods that do not show oo at all. "We are using a group of objects at run time, not classes (descriptions of objects) (what you have in runtime is a bunch to objects, not classes--animals, not their descr Iptions) "

The next question is more than I can bear (I really want to scare the children): Allen Holub The definition of the object in a comprehensive negative. He thinks that objects are a set of abilities (capabilities) that are defined by what it can do, rather than by how he does it--a point of how the data is done. He argues that objects are by no means a data structure (including a set of methods used to manipulate data structures) [1]. Allen Holu uses more realistic terms to define an object as an object that is defined by the message he accepts and sends, and the method of handling the messages makes up the object's unique and external interface [2].

Third, Allen Holub that the advantage of OO is that a program is easier to develop and maintain, and that it does not do this with multiple layers of architecture (I've always thought that one of the benefits of multi-tier architecture is that it provides better maintenance scenarios). The original text of this paragraph can not be found, but it is quite reasonable.

......