Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
Programming is full of rules. When you first learn a language, you spend a lot of time memorizing what can and can't be done with that language, syntax rules, keywords, sometimes things like memory management, perhaps you can't create a variable name that has a number at the beginning, or whether you must break in every case of a switch statement. And in one language you can send a message to a released object, another language you can't. But in one way the situation with these is easy. If you do these things, you'll have an obvious problem, your code won't compile or your program will crash.
With Object-Oriented Design it's not that straightforward, and there is very little in the way of enforced rules. If you have a situation where you could use inheritance and you don't and instead create several classes that duplicate 90% of each other, what will happen? The program won't crash, there will be no messages. If you make every member of every class public and violate encapsulation having every object reach directly into every other object, again, the program will compile, and it will run.
Indeed, if you combined every single concept in your application into one massive class that acted like a completely procedural program that could have been written in COBOL or C, well, you could do that and no alarm bells would ring. But none of these would be good, and you'd be creating code that's hard to understand how to even read. Code that breaks easily, that's much harder to maintain, and you'll hate the idea of adding a new feature or even doing basic bug fixing, because you'll have fragile or brittle software, and that one small modification could fracture the entire system.
So good object orientation practices do not automatically get imposed, it's up to us. We might not have enforced rules, but we do have guidelines, and we have principles that we can use. So in this section I am going to talk a little bit about some popular object-oriented development principles. Now, these aren't Design Patterns, and that they don't focused situation. They are general principles, things to stay conscious of, and occasionally check back with as you create and iterate through your class design and building your software.
So first, we'll just cover some general development principles, then we'll cover two sets of well-known Object-Oriented Design principles, grouped together under the acronyms SOLID and GRASP. Now, these aren't as generic as just the concepts of abstraction, polymorphism, inheritance, and encapsulation, they use those ideas as a starting point and give you some more guidelines so that you can ask, "Did I design this class well?" and have a good answer to that question.
Get unlimited access to all courses for just $25/month.Become a member
82 Video lessons · 97255 Viewers
61 Video lessons · 84534 Viewers
71 Video lessons · 68734 Viewers
56 Video lessons · 101220 Viewers
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.
Your file was successfully uploaded.