Going straight to the code editor for programming seems like progress, but that progress is often an illusion. Taking the time to think about your project before you sit down to code will save you time and prevent costly backtracking down the road. If you're not sure what to expect from this course, an index card, paper, pencil, or whiteboard are the main tools you'll need.
In this course we will talk about a lot of ideas, and when you first hear some of them it's easy to interpret object orientation as this dry academic body of knowledge. You will hear words like Polymorphism, Abstraction, Composition, many others, and it can sometimes sound like a philosophical exercise that just can't have much in the way of practical value, but make no mistake, this is a course about building better and more complex applications. How to understand what you need to do, get your code written faster with less pain, less bugs, and more flexibility.
That's why we do this. What we want to avoid is ever sitting down in front of a code editor or IDE looking into a blinking cursor and thinking, now what do I do? Because when that is your question, the answer is always step away from the code. Step away from the code and pick up an index card, or paper and pencil, or grab a whiteboard. So expect the most of this course we'll do with this level of technology, and using these more will make you a better programmer.
But there are two ideas that could be getting in your way, and I want to cover those. First is recognizing any level of resistance that you have to doing this work on paper, to doing work on the whiteboard. Programmers want to run straight to the code editor. Start writing some code, any code. It's an easy emotional hit, this feels like progress but it's often an illusion. So it's easy to think that if you just get started you can figure out everything else along the way. Go by the seat of the pants, and sometimes that might even work.
More often, it leads to code that's abandoned, to progress that slows down, to the realization that you have to back out days or weeks of work. Because you should have thought about it just a little bit more before you started typing. So all these ideas, everything we are doing here lead to greater clarity in our code, and if they don't something is wrong. Now the second misconception is that knowing this material will somehow limit your ability to be creative, tie you into some formalized fixed way of doing things, and the opposite is true.
This is simply a profession vocabulary that gives you clarity about what you are doing and the ability to communicate that. Now if you are a graphic designer, you would have knowledge of alignment, color balance, typography, Kerning and Leading, pixels versus points. If you are a musician, you know the difference between a chord and a scale, key and tempo, harmony and melody, and knowing these does not limit you. Knowing these frees you from making the same dumb mistakes time and time again. Programming is always a creative act.
Give a hundred talented programmers the same problem, you will get a hundred different results, and the concepts and ideas of object orientation don't change that. There is no one right way to go about this. Object-oriented design is not by itself a formulized process. It is a set of ideas and techniques. These and others that you will use as part of your own process.
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.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles