Object-oriented concepts. Object-oriented development: Defining classes. Other than the name of the class, next most obvious thing about them, are their methods. After all, this simplest tool that we have CRC cards starts with class then responsibilities. Methods are how responsibilities are accessed. Methods are discovered by looking at sequence diagrams, communication diagrams, activity and state machine diagrams. Most come from finding actions verbs in the use case descriptions. Others support runtime infrastructure such as construction, destruction, string conversion. Actual data should always be private except for exposed constants. When we do want to expose data as part of an interface, it should be done as a managed property, a parameter, or return value. As we've seen, the details of properties or language-specific, although the concept of property is language agnostic. At the very end of this video, we'll look at how we talk about properties in terms of UML. Properties, parameters and return values can be found in the various types of diagrams that document object interactions. Also the roles that adorn associations are often mapped to properties that allow navigation of those associations. All forms of data should be given meaningful names and types. As we work on methods and data, remember that if we're engaged in test-driven development, we'll be looking at the various diagrams that contribute to use cases and these will provide guidance on writing tests. The tests will drive the solution code. We don't create methods, properties, parameters, etc, until there is a test that fails because those things are needed. Remember that with test-driven development, we implement only as much as we need to cause a failing test to pass. Don't work ahead. You'll get there eventually. Even though not all languages in force visibility or access control methods and data should be marked with modifiers. UML supports the same notion of visibility that Java does. Public for things that are part of our interface, private for things that are not, protected for things to be exposed to sub-types, and package for others in our package. But even though access levels are language specific concepts, we do want to emphasize the difference between what constitutes the documented interface to an entity from its internals. As object or an programmers, we love reuse. We live for reuse. If we're doing test-driven development, we formally address reuse and inheritance as part of the refactoring phase after making it test-pass. Of course, if we already know that something is going to be a subclass, because we already have the necessary parts of the inheritance tree for it to fit into, we would make it a subclass right off the bat. Likewise, we love polymorphism and we should be looking for opportunities to use it are two methods was different names actually synonyms that semantically should be polymorphic. The information we need for a class diagram comes from various other UML diagrams. Here is an example of a UML class diagram. How much we flesh out and when will depend on our methodology and test-driven development. This diagram would reflect not some theoretical complete state of the class, but rather everything that we have thus far needed to pass tests that we have written. The diagram includes private data that developers have determined they need internally, public interface and a couple of protected methods. For purpose of our discussion, public is the documented interface for a class, private is the internal implementation of a class and documented only for other people who work on the internals and protected as a defined contract between super classes and sub classes. One other observation about this diagram. This is a UML model, not a description of code. A lot of people tend to forget the difference and I'm going to use this diagram to point out a difference. Notice that there are several pieces of data actually marked as public, but it shouldn't all data be private. Where those methods and red? The original diagram had all of the data marked private and had those explicit methods for getting and in one case, modifying the data. In UML, public properties can be visualized as public data. We don't need to explicitly add setters and getters to the UML diagram. The methods that I've marked in red should be removed from the diagram. Programmers and any co-generation tools just need to correctly translate the UML diagram. In Python, public data should be exposed as properties. In Java, public data should be exposed via setter and getter methods. But those do not need to be placed on the UML diagram. As a view, ML 2.5. we can mark things that should have a getter but not a setter as read-only as shown in this updated diagram. Developing an object-oriented solution requires a change in development mindset. We develop solutions as a graph of collaborating entities called objects. Each object has its behavior defined by a class and communicates with its collaborators by sending messages. We learn about and learn to use well-thought out design patterns we build using frameworks. We encapsulate implementation, hiding it behind polymorphic interfaces, we aggressively exploit inheritance and other forms of reuse. Fortunately, multitudes of years of experience are available to us in the form of education, commercial and open source frameworks, helpful communities of users and more. In our next video, we will discuss bringing us to a network-based Solution.
