Start learning with our library of video tutorials taught by experts. Get started
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
Now let's explore one more set of object-oriented design principles. This is GRASP, short for General Responsibility Assignment Software Patterns. And as you will see, the principles here take a slightly different perspective than the five principles found in SOLID, although there is certainly some crossover. GRASP tends to take a responsibility focus as in who creates this object, who is in charge of how these objects talk to each other, who takes care of passing all messages received from a user interface? Now SOLID and GRASP don't conflict with each other, they are not competing sets, you might choose to use one or both or neither.
And there are nine ideas in GRASP, but again, it's not about memorizing these. I'm just trying to provide an introduction to the fact that they exist. This is not dogma, these are not rules, but you may find GRASP a useful learning tool to keep in mind while drawing up UML diagrams to provide some techniques for figuring out the responsibilities of your objects. First up, I'm going to talk about the principle called Expert or Information Expert. This is one of the simplest, most basic ideas--refers to the idea that a class should be responsible for itself, that if there is a responsibility--and we are asking where does this go--we give it to the class that has the most information needed to fulfill it, whether that's storing a piece of data or performing some service.
Let's say we are working with three objects, Customer, Shopping Cart, Item. And we realize the Customer wants to know the current total of all items in the cart. Now there is nothing that would stop us from calculating that data and storing it inside Customer object, but if you think about it, it's the Shopping Cart that knows the most about all the items inside it, it's the Shopping Cart that should be responsible for that, an object who takes care of itself. That's the idea of the Information Expert or the Expert principle.
Next, we have the idea of CREATOR. Who is responsible for creating an object? We can often look at our Class diagram and ask this question about a lot of your classes. It's often easy to figure out that there are interactions between objects, but not so easy to determine how those objects are created in the first place, how they come into being. Sometimes drawing up a Sequence diagram can help, but if we are not sure, the CREATOR role asks a few questions, such as does one object contain another, the idea of composition, does one object very closely use another or will one object know enough to make another object? And if so, it would seem to make sense to nominate those objects as taking that CREATOR role and making it apparent which objects are responsible for creating other objects.
Next, we have the idea all LOW COUPLING and HIGH COHESION. Now LOW COUPLING is something that's a desirable, and you'll hear this phrase from developers who have never worked with GRASP or Principles or SOLID principles, it's a common phrase in development, and it simply means to reduce the amount of required connections between objects. If one object needs to connect tightly to five other objects and call 20 different methods just to work, you have HIGH COUPLING. Lots of dependencies meaning lots of potential for breaking things if you make a change to any of these objects.
The aim is for LOW COUPLING, reducing dependencies. Now LOW COUPLING does not mean no coupling. Objects do need to know about each other, but as much as possible they should do what they can with the minimum of other objects--as many as necessary but as few as possible. You will often hear about Coupling and Cohesion being talked about in the same sentence. Cohesion is a measure of how focused the internal behavior of a class is. Are all its behaviors related to that single responsibility? If so, it has HIGH COHESION.
If for example, it's a God Object with multiple behaviors, all of which have nothing to do with each other, it has LOW COHESION. What we want is LOW COUPLING, and we want HIGH COHESION, and you will find that these two ideas are actually related to several other principles as we go through these. For example, the next idea, something called CONTROLLER. If we have a user interface and also some business- related classes, we don't want to have HIGH COUPLING between them to actually tie them directly together, where the User Interface elements have to know about the Business Objects and the Business Objects have to know about the User Interface elements.
So it's very common to create a new class called a CONTROLLER class just for the purpose of going between them. So we don't expect the Business Object to update the actual screen, nor do we expect the screen--the buttons, and windows--to actually talk directly to the Business object. The CONTROLLER stands between them. And there is a common programming pattern called Model View Controller which is an example of using this. And it does lead to the idea that it's perfectly normal for object to exist that takes a role in a program that isn't a real world Business Object or concept, it's still just a well- described position, a well-described idea inside the application itself.
This is just a specific example of that, and it leads to the next idea, that of PURE FABRICATION. What if there's something that needs to exist in the application that doesn't announce itself as an obvious class or real-world object? What if you have behavior that doesn't naturally fit in existing classes? Well, rather than force that behavior into an existing class where it doesn't belong--which means we are decreasing Cohesion-- we instead invent, we fabricate a new class.
That class might not have existed in our conceptual model, but it needs to exist now. And there's nothing wrong with creating a class that represents pure functionality as long as you know why you're doing it. PURE FABRICATION leads us to the next idea of Indirection. This is the idea that we can decrease coupling between objects. If you have multiple objects that need to talk to each other, it's very easy to have HIGH COUPLING between them where there is a lot of dependencies. And what we can do instead is reduce those direct connections and put an indirection object in between them to simplify the amount of connections that each object has to make.
The next principle we've been exploring several times, which is POLYMORPHISM-- and I say automatically here because the opposite of this would be having to write code that checks the existence of an object and checks to see what particular type it is. We don't want to do that, we want to reduce that kind of checking as much as possible and just have it work polymorphically and automatically, which of course means we are thinking about Inheritance, we are thinking class design. And finally, we have Protected Variations. This is the widest, most overreaching idea.
How to design a system so that changes and variations have the minimum impact on what already exists. Here, as a principle it means we try to identify the most likely points of change so we can make doubly sure that we create a framework around our application that protects the most sensitive pieces. And here's the thing, most of the concepts we have been exploring all along are simply ways of doing this, things like encapsulation and data-hiding, making your attributes private. Well, that's just one way of protecting your classes from change.
Interfaces are another area where we can support formality, even add more later, but we are not enforcing specific behavior. The Liskov substitution principle, child classes should always work when treated as their parent classes is another. The open/closed principle in SOLID that we can add, but we try not to change code that works already is yet another. And even though they may be wrapped up in complex sounding terminology, this is what object-oriented design principles and patterns and practices are all designed to support, to allow us to figure out more approaches to use when we run into sticking points, and to write readable, maintainable, flexible code.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.