NET 5. NET developers, application developers, and software engineers who want to develop. NET applications with proven techniques and build error-free applications.
This book also attracts fresh graduates and entry-level developers as long as basic knowledge about. NET is known to them. C Fundamentals 2. Introduction to. NET 5 3. Basic Concepts of Object-Oriented Programming 4. Interfaces in C 5. Encapsulation and Polymorphism in C 6. Abstract Factory 8. Abstract Factory 9. Prototype Factory Method Adapter Cohesion describes how strongly the internal contents of a routine are 1.
McConnell, S. Note: McConnell did not invent these terms, we just happen to like his definitions of them best. Coupling describes how strongly a rou- tine is related to other routines. The goal is to create routines with internal integrity strong cohesion and small, direct, visi- ble, and flexible relations to other routines loose coupling.
In fact, bugs of this type lead me to a rather startling observation: We really do not spend much time fixing bugs. I think fixing bugs takes a short period of time in the maintenance and debugging process. The overwhelming amount of time spent in maintenance and debugging is on finding bugs and taking the time to avoid unwanted side effects. The actual fix is relatively short! Since unwanted side effects are often the hardest bugs to find, hav- ing a function that touches many different pieces of data makes it more likely that a change in requirements will result in a problem.
Functional decompo- With functional decomposition, changing requirements causes my sition focuses on the software development and maintenance efforts to thrash.
I am wrong thing focused primarily on the functions. Changes to one set of functions or data impact other sets of functions and other sets of data, which in turn impact other functions that must be changed. Like a snow- ball that picks up snow as it rolls downhill, a focus on functions leads to a cascade of changes from which it is difficult to escape. Dealing with Changing Requirements How do people do To figure out a way around the problem of changing requirements things?
One of your responsibilities is to make sure everyone knows how to get to their next class. If you were to follow a structured programming approach, you might do the following: 1.
Get list of people in the class. For each person on this list: a. Find the next class they are taking. Find the location of that class. Tell the person how to get to their next class. To do this would require the following procedures: 1. A way of getting the list of people in the class 2. A way of getting the schedule for each person in the class 3. A program that gives someone directions from your classroom to any other classroom 4.
A control program that works for each person in the class and does the required steps for each person I doubt that you would actually follow this approach. Please use them to go to your next classroom.
What is the difference between these approaches? No one other than you is responsible for anything. You will go crazy! In the first bility from yourself case, you are responsible for everything; in the second case, stu- to individuals.
In both cases, the same things must be implemented, but the organization is very different. What is the impact of this? Suppose I am now told to give special instructions to graduate stu- dents who are assisting at the conference. Perhaps they need to col- lect course evaluations and take them to the conference office before they can go to the next class. In the first case, I would have to modify the control program to distinguish the graduate students from the undergraduates, and then give special instructions to the graduate students.
Why the difference? This is a significant difference for the control program. In one case, it would have to be modified every time there was a new category of students with special instructions that they might be expected to follow. In the other one, new categories of students have to be responsible for themselves. What makes it There are three different things going on that make this happen. Note that to accom- plish this, a person must also be aware of what type of student he or she is.
Fowler, M. In other words, you are telling people what you want, not how to do it. However, the way they go to their next class is very specific. They are following specific instructions and in doing so are working at the implementation level.
Communicating at one level conceptually while performing at another level implementation results in the requestor the instructor not knowing exactly what is happening, only knowing conceptually what is happening.
This can be very powerful. The Object-Oriented Paradigm Using objects shifts The object-oriented paradigm is centered on the concept of the responsibility to a object. Everything is focused on objects. I write code organized more local level around objects, not functions.
What is an object? Objects have traditionally been defined as data with methods the object-oriented term for functions. Unfortunately, this is a very limiting way of looking at objects. When I talk about the data of an object, these can be sim- ple things like numbers and character strings, or they can be other objects. The advantage of using objects is that I can define things that are responsible for themselves. See Table Objects inherently know what type they are.
The data in an object allow it to know what state it is in and the code in the object allows it to function properly that is, do what it is supposed to do. Is Responsible For. Student Knowing which classroom they are in Knowing which classroom they are to go to next Going from one classroom to the next Instructor Telling people to go to next classroom Classroom Having a location Direction giver Given two classrooms, giving directions from one classroom to the other In this case, the objects were identified by looking at the entities in the problem domain.
I identified the responsibilities or methods for each object by looking at what these entities need to do. This is consistent with the technique of finding objects by looking for the nouns in the requirements and finding methods by looking for verbs. I find this technique to be quite limiting and will show a bet- ter way throughout the book. For now, it is a way to get us started. The best way to think about what an object is, is to think of it as How to think about something with responsibilities.
A good design rule is that objects objects should be responsible for themselves and should have those responsibilities clearly defined.
This is why I say one of the respon- sibilities of a student object is knowing how to go from one class- room to the next. Unfortunately, object-oriented design is often taught and talked about only at the implementation level—in terms of code and data—rather than at the conceptual or specification level. But there is great power in thinking about objects in these latter ways as well! Objects have Since objects have responsibilities and objects are responsible for interfaces for other themselves, there has to be a way to tell objects what to do.
Many methods of an object will be identified as callable by other objects. For example, in the classroom example, I could write the Student object with the method gotoNextClassroom.
I would not need to pass any parameters in because each student would be responsi- ble for itself. But what if I want to have more kinds of students? It seems inefficient for each student type to have its own set of methods to tell it what it can do, espe- cially for tasks that are common to all students. Then, I can have all manner of specialized students, each of whom has to keep track of his or her own private information. In object-oriented terms, this general student is called a class.
A class is a definition of the behavior of an object. To get an object, I tell the program that I want a new object of this Objects are type that is, the class that the object belongs to. This new object is instances of classes called an instance of the class. Creating instances of a class is called instantiation.
The program would look like this: in the example 1. Start the control program. Instantiate the collection of students in the classroom. Tell the collection to have the students go to their next class. The collection tells each student to go to their next class. Each student: a. Finds where his next class is b. Goes there 4. The need for an This works fine until I need to add another student type, such as abstract type the graduate student. I have a dilemma.
It appears that I must allow any type of student into the collection either regular or graduate student. The prob- lem facing me is how do I want the collection to refer to its constit- uents? Since I am talking about implementing this in code, the collection will actually be an array or something of some type of object. If the collection were named something like, Regular- Students, then I would not be able to put GraduateStudents into the collection.
The solution is straightforward. I need a general type that encom- passes more than one specific type. In object-oriented terms, we call Student an abstract class. Abstract classes Abstract classes define what other, related, classes can do. Such a class is often called a concrete class because it repre- sents a specific, or nonchanging, implementation of a concept. In the example, the abstract class is Student. There are two types of Students represented by the concrete classes, Regular- Students and GraduateStudents.
This type of relationship is called an is-a relationship, which is for- mally called inheritance. Thus, the RegularStudent class inherits from Student. Other ways to say this would be, the Graduate- Student derives from, specializes, or is a subclass of Student. Abstract classes act as placeholders for other classes. I use them to Abstract classes act as define the methods their derived classes must implement. Abstract placeholders for classes can also contain common methods that can be used by all der- other classes ivations.
Whether a derived class uses the default behavior or replaces it with its own variation is up to the derivation this is con- sistent with the mandate that objects be responsible for themselves. This means that I can have the controller contain Students. The reference type used will be Student. The compiler can check that anything referred to by this Student reference is, in fact, a kind of Student. Abstract classes are more than classes that do not get instantiated.
Abstract classes are often described as classes that do not get instantiated. This definition is accurate—at the implementation level. But that is too limited. It is more helpful to define abstract classes at the conceptual level. Thus, at the conceptual level, abstract classes are simply placeholders for other classes.
That is, they give us a way to assign a name to a set of related classes. This lets us treat this set as one concept. In the object-oriented paradigm, you must constantly think about your problem from all three levels of perspective. Earlier, I men- tioned the concept of the public interface—those methods that are accessible by other objects. Encapsulation This leads to the concept of encapsulation. Encapsulation has often been described simply as hiding data. Objects generally do not expose their internal data members to the outside world that is, their visibility is protected or private.
But encapsulation refers to more than hiding data. In general, encapsulation means any kind of hiding. In the example, the instructor did not know which were the regular students and which were the graduate students. The type of student is hidden from the instructor I am encapsulating the type of stu- dent. As you will see later in the book, this is a very important concept.
Polymorphism Another term to learn is polymorphism. In object-oriented languages, we often refer to objects with one type of reference that is an abstract class type. However, what we are actually referring to are specific instances of classes derived from their abstract classes. Thus, when I tell the objects to do something conceptually through the abstract reference, I get different behavior, depending upon the specific type of derived object I have.
Polymorphism derives from poly meaning many and morph meaning form. This is an appropriate name because I have many differ- ent forms of behavior for the same call. I implement these by writing a class in code that defines data members the variables associated with the objects and meth- ods the functions associated with the objects. Class The repository of methods. Defines the data members of objects. Code is organized around the class. Encapsulation Typically defined as data-hiding, but better thought of as any kind of hiding.
Inheritance Having one class be a special kind of another class. These specialized classes are called derivations of the base class the initial class. The base class is some- times called the superclass while the derived classes are sometimes called the subclasses. Instance A particular example of a class it is always an object.
Instantiation The process of creating an instance of a class. Polymorphism Being able to refer to different derivations of a class in the same way, but getting the behavior appropriate to the derived class being referred to. Perspectives There are three different perspectives for looking at objects: conceptual, specification, and implementation. These distinctions are helpful in understanding the relationship between abstract classes and their deriva- tions.
The abstract class defines how to solve things conceptually. It also gives the specification for commu- nicating with any object derived from it. Each derivation provides the specific implementation needed. How would I implement it in an object-oriented man- ner? Remember that it has to do the following: 1. To solve this in an object-oriented manner, I need to define the objects and the responsibilities they would have.
Main program creates an instance of the database object. Main program asks the database object to find the set of shapes I am interested in and to instantiate a collection object contain- ing all of the shapes actually, it will instantiate circles and squares that the collection will hold.
Main program asks the collection to sort the shapes. Main program asks the collection to display the shapes. The collection asks each shape it contains to display itself. Each shape displays itself using the Display object according to the type of shape I have. To introduce a new kind of shape, only two steps are required: — Create a new derivation of Shape that defines the shape.
To change the method for sorting the shapes, only one step is required: — Modify the method in Collection. Every shape will use the new algorithm. Bottom line: The object-oriented approach has limited the impact of changing requirements. Benefit: Finally, consider the problem of unwanted side effects that arise reduced side effects when functions are changed.
This kind of bug is addressed effec- tively with encapsulation. The internals of objects are unknown to other objects. If I use encapsulation and follow the strategy that objects are responsible for themselves, then the only way to affect an object will be to call a method on that object. Encapsulation saves us. Special Object Methods Creating and I have talked about methods that are called by other objects or pos- destroying sibly used by an object itself. What happens when they go away?
If objects are self- contained units, then it would be a good idea to have methods to handle these situations. These special methods do, in fact, exist and are called constructors and destructors.
A constructor is a special method that is automatically called when Constructors the object is created. Its purpose is to handle starting up the object. The up, an object constructor is the natural place to do initializations, set default information, set up relationships with other objects, or do anything else that is needed to make a well-defined object.
All object-ori- ented languages look for a constructor method and execute it when the object is created. By using constructors properly it is easier to eliminate or at least minimize uninitialized variables. This type of error usually occurs from carelessness on the part of the developer.
By having a set, con- sistent place for all initializations throughout your code that is, the constructors of your objects it is easier to ensure that initializations take place. Errors caused by uninitialized variables are easy to fix but hard to find, so this convention with the automatic calling of the constructor can increase the efficiency of programmers.
A destructor is a special method that helps an object clean up after Destructors clean up itself when the object goes out of existence; that is, when the object an object when it is is destroyed.
All object-oriented languages look for a destructor no longer needed method and execute it when the object is being deleted. Destructors are typically used for releasing resources when objects are no longer needed. Summary In this chapter In this chapter, I have shown how object orientation helps us mini- mize consequences of shifting requirements on a system and how it contrasts with functional decomposition.
I covered a number of the essential concepts in object-oriented pro- gramming and have introduced and described the primary termi- nology. These are essential to understanding the concepts in the rest of this book. See Tables and Table Object-Oriented Concepts Concept Review Functional Structured programmers usually approach program design with functional decomposition decomposition.
Functional decomposition is the method of breaking down a problem into smaller and smaller functions. Each function is subdivided until it is manageable. Changing Changing requirements are inherent to the development process. Rather requirements than blaming users or ourselves about the seemingly impossible task of getting good and complete requirements, we should use development methods that deal with changing requirements more effectively.
Objects Objects are defined by their responsibilities. Objects simplify the tasks of programs that use them by being responsible for themselves. Constructors and An object has special methods that are called when it is created and destructors deleted. All object-oriented languages use constructors and destructors to help manage objects. Abstract classes are never instantiated. Attribute Data associated with an object also called a data member.
Class Blueprint of an object—defines the methods and data of an object of its type. Constructor Special method that is invoked when an object is created. Encapsulation Any kind of hiding. Objects encapsulate their data. Abstract classes encapsulate their derived concrete classes. Derived class A class that is specialized from a superclass. Contains all of the attributes and methods of the superclass but may also contain other attributes or dif- ferent method implementations.
Destructor Special method that is invoked when an object is deleted. Functional A method of analysis in which a problem is broken into smaller and decomposition smaller functions. Inheritance The way that a class is specialized, used to relate derived classes from their abstractions.
Instance A particular object of a class. Member Either data or method of a class. Method Functions that are associated with an object. Object An entity with responsibilities. A special, self-contained holder of both data and methods that operate on that data. Polymorphism The ability of related objects to implement methods that are specialized to their type. Superclass A class from which other classes are derived. Contains the master defini- tions of attributes and methods that all derived classes will use and possi- bly will override.
If you do not already know the UML, this chapter will give you the minimal understanding you will need to be able to read the diagrams contained in this book. The UML is a visual language meaning a drawing notation with UML offers many semantics used to create models of programs. By models of kinds of modeling pro-grams, I mean a diagrammatic representation of the programs diagrams in which one can see the relationships between the objects in the code.
Each diagram shows the relationships among the different sets of entities, depending upon the purpose of the diagram. Use the UML Diagram In the analysis phase Use Case Diagrams, which involve entities interacting with the system say, users and other systems and the function points that I need to implement. Activity Diagrams, which focus on workflow of the problem domain the actual space where people and other agents are working, the sub- ject area of the program rather than the logic flow of the program.
Looking at object Interaction Diagrams, which show how specific interactions objects interact with each other. Since they deal with specific cases rather than general situations, they are helpful both when checking requirements and when checking designs. The most popular kind of Interaction Diagram is the Sequence Diagram.
In the design phase Class Diagrams, which detail the relationships between the classes. Looking at an object's State Diagrams, which detail the different states behaviors that differ an object may be in as well as the transitions based upon the state between these states.
I will not talk about these diagrams here. The UML is used primarily for communication— with myself, my Principally for team members, and with my customers. Poor requirements either communications incomplete or inaccurate are ubiquitous in the field of software development.
The UML gives us tools to gather better requirements. The UML gives a way to determine if my understanding of the sys- For clarity tern is the same as others'. Because systems are complex and have different types of information that must be conveyed, it offers dif- ferent diagrams specializing in the different types of information.
One easy way to see the value of the UML is to recall your last sev- For precision eral design reviews. If you have ever been in a review where some- one starts talking about their code and describes it without a modeling language like the UML, almost certainly their talk was both confusing as well as being much longer than necessary.
The UML is not only a better way of describing object-oriented designs, it also forces the designer to think through his or her approach since it must be written down.
It both The basic modeling describes classes and shows the relationships between them. The first example is called composition while the second is called aggregation. First, each rectangle showing class represents a class. I have three different ways of showing these. I would use this type of class representation when more detailed information is not needed. The presented definition is, in fact, consistent with the UML's.
This illustrates some of the moti- vation for the UML; before it came out there were several different modeling lan- guages, each with its own notation and terms. In this case, the Square2 has the method display.
In this case, the minus sign - before the data member length which is of type double indicates that this data member's value is private, that is it is unavailable to anything other than the object to which it belongs. Shalloway and Trott don't just introduce a laundry list of patterns: they explain why each pattern works, the organizing principles upon which the pattern is based, and above all, how the patterns work together in real world object-oriented designs.
For all software developers, programmers, architects, and project managers who want to succeed with patterns. I would expect that readers with a basic understanding of object-oriented programming and design would find this book useful, before approaching design patterns completely.
Design Patterns Explained complements the existing design patterns texts and may perform a very useful role, fitting between introductory texts such as UML Distilled and the more advanced patterns A how-to guide for Java programmers who want to use design patterns when developing real-world enterprise applicationsThis practical book explores the subject of design patterns, or patterns that occur in the design phase of a project's life cycle.
Alan tried them out in his courses and we refined some more. I learned much about how to design objects, and alam common design patterns.
Building on their best-selling First Edition, Shalloway and Trott have thoroughly updated this book to reflect new software design trends, patterns, and implementation techniques. Using the Decorator Pattern. Alan Shalloway is founder, CEO, and principal consultant of Net Objectives, an object-oriented consulting and training organization. Explore the Home Gift Guide. The Factory Method Pattern. This raises the level of discussion among developers, especially at the conceptual level.
Their terminology is bandied about every day in the technical and eventhe popular press. Beginning with a complete overview of the fundamentals of patterns, Design Patterns Explained stresses the importance of analysis and design. And by teaching the guidingprinciples and strategies, my students were able to create designs ofcomparable quality to the patterns themselves.
0コメント