Exploring general development principles
Video: Exploring general development principlesFirst, we're going to go through some general development principles, some obvious and some not so obvious. Now, one well-known idea in software development--and not just limited to Object-Oriented Design but still worth mentioning--is D-R-Y or DRY: Don't Repeat Yourself. Now, the very obvious impact of this is we don't copy and paste unchanged blocks of code from one place to another, we contain them in functions or methods. But what's not so obvious is the idea that this can be applied in multiple areas.
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.
- 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
Exploring general development principles
First, we're going to go through some general development principles, some obvious and some not so obvious. Now, one well-known idea in software development--and not just limited to Object-Oriented Design but still worth mentioning--is D-R-Y or DRY: Don't Repeat Yourself. Now, the very obvious impact of this is we don't copy and paste unchanged blocks of code from one place to another, we contain them in functions or methods. But what's not so obvious is the idea that this can be applied in multiple areas.
We don't just want to avoid duplication in code, but in our database schemas, in our diagrams, in our documentation, and more than that, there should be a single source of truth. There should be one place in our system that deals with the particular problem. One place that that gets taken care of, whether that's handling a business problem or storing or calculating a piece of data. And then there's YAGNI, Y-A-G-N-I: You Ain't Gonna Need It. Solve the problems that you know exist, don't write speculative code, solve today's problems.
Now, this is why we want to at the very least have basic user stories or use cases so that when we're buried in our code editor we're not actually trying to figure out what we're actually attempting to solve. It's very tempting for developers when writing code, when solving a problem, to add in some extra functionality for something that seems like it might be necessary in the future. But that's not a great thing to do. Everything you add is code that needs to be maintained, it needs to be tested, it needs to be debugged, and it's easy for this to lead to feature-creep, or just general code bloat.
So unnecessary code and duplicated code are what are sometimes referred to as a Code Smell. Code Smells are a great term for when reading code, either your own, or someone else's. The code may be valid, it may work, it may compile, but there is something about it that just doesn't smell right. It's often a clue, a warning sign of a deeper problem, and here are just a few examples of what I mean by a Code Smell. One would be the idea of a long method. You open up a method to read it, it has got 250, 300 lines.
This is the kind of thing that really needs to be split up into much smaller methods. Or working with very short or very long identifiers. Aside from using letters like I for indexes and iteration, you shouldn't be expecting to see variables called A and B and C in real code. Another clue would be pointless comments. Yes, code should be commented and code should be well-written so that it's readable and the code comments itself. We do want comments, but we don't want comments like this, where the comment is actually longer than the code that it's describing.
More specifically when doing Object- Oriented Design, we have Code Smells like the God object. This is where you have one master object that tries to do everything in the program, or at least one object that seems to be doing very different responsibilities that have nothing to do with each other. This is very common when procedural programmers start working in an object-oriented language, but the only change they learned was the syntax of the language and not the principles behind them. It's a clue that this needs to be revisited and broken apart into the right kind of objects.
And then there's Feature envy. If a class seems to do very little except use all the methods of one other class, it's another sign that you need to rethink the roles of one or the other. So those are just a few examples, and in the next section I'm going to cover some more formalized and object- oriented specific principles that we can use.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.