Join Anton Delsink for an in-depth discussion in this video Theory vs. practice, part of Object Oriented Programming with C#.
- [Instructor] In this chapter, let me just briefly address the difference between theory and practice. In some of the previous courses, you've learned some of the theory about object-oriented programming, and so you were able to write down a description of a scenario or a requirement and then mechanically translate that into object-oriented concepts. So for example, when you describe a use case, you'd be able extract some of the classes, objects, some of the methods that you can identify in the language, and so that's a really great start when it comes to object oriented design, in that you have a starting point.
You have a reference from your use case, that can translate into something mechanical in terms of language features that you can apply. In this course, we're going to go the opposite way. We are going to make the assumption that the language has object-oriented features and we will pick those features that are useful to us to solve a particular problem. So instead of writing out use cases and documenting extensive requirements, we'll take a concept and then see how that concept can be implemented using object-oriented techniques.
And so this is just a learning mechanism. You will of course have to find a balance between theory and practice, in that in theory, we can simplify things, we can make it really focused on a particular idea as we go through training like this, whereas in practice, we will have to also deal with edge cases and all the nuances that come with real-world systems. So with that said, after this course, you should take a look at additional courses that help deal with how do we do object-oriented programming within certain contexts and in particular, dealing with how do we define whether our design is any good at all? And so let me touch on those two items briefly.
So, as you've gone through the previous courses, you might have taken the opportunity to actually try and create an object-oriented design, and so the question would arise, when is the design good enough? And so, when you look at a particular design, there are design principles that we can apply so we can evaluate, sort of like a code review, but we can evaluate the design based on these principles. This is an entire course worth of content, and it's worth looking at that additional course and content as a way to add how you would evaluate a design, so not just be able to come up with one, not just being able to implement what you've designed, but also evaluate that design based on these principles.
Now, we don't have time to go through all of them here and now, but what you'll find, as we go through these examples, and as you then study the SOLID principles in the future, you'll be able to refer back to our examples, and see that we would have made quite a few compromises and not fully lived up to the SOLID principles in our examples. So there's a nice opportunity to take our examples from this course and actually improve upon them by applying the SOLID principles. In addition to those design principles that you can use to evaluate your object-oriented design, you should also consider the relevance of testing.
For a lot of us, test-driven development is a way we like to approach problem solving, but even without a rigid test-driven development approach, it's worth recognizing that there is, to quote Michael Feathers, "a synergy between testability and good design." If you find that your code and your object-oriented design is hard to test, there's probably an opportunity to improve upon that design by making it more testable. Or to put it another way, if your design is testable, you're probably on the right path towards good design.
So, we're going to use unit tests throughout this course as a starting point for writing our code, and it is essentially a way for us to try before we buy, to try to use our code in code, before committing to a larger design. And so I would encourage you, I've made this mistake many times, do use visualization tools to design, but do also make a point of taking the client's perspective, the client of your API, the user of your code, because from their perspective, it will look very different in code from what you see on a whiteboard, what you see in a visualization tool, and it's worth having both perspectives.
So, enough said about theory versus practice. Let's take a look at some examples.
- Abstract classes
- Processing text with StreamReader
- IEnumerable and yield return
- Windows Forms controls
- Windows Forms with and without the designer
- Adding, organizing, and testing forms
- Creating classes