Java Fundamentals: Object-oriented Design

Simply programming in an OO language does not make your program object oriented. This course teaches you how to leverage essential object-oriented principles to write solid, maintainable code, while avoiding common pitfalls.
Course info
Rating
(96)
Level
Beginner
Updated
Jan 20, 2017
Duration
1h 59m
Table of contents
Description
Course info
Rating
(96)
Level
Beginner
Updated
Jan 20, 2017
Duration
1h 59m
Description

Simply using an OO language like Java does not make your program object oriented. In fact, when used incorrectly, OO-language features can make your program bloated, overly complex, and impossible to maintain. This course, Java Fundamentals: Object-oriented Design, teaches you how to write effective production-quality OO systems by leveraging the basic principles of good OO design. It assumes you know the nuts and bolts of Java, and goes beyond those to teach you how to write effective, production-quality code in Java, or any other OO language. You will learn how to structure your code to be highly maintainable and easy to modify. You'll learn about the pitfalls of many common idioms (like getters and setters and too-open subclassing). You'll also see the SOLID principles used to solve real-world programming issues as well as see a lot of code that demonstrates the principles. When you're done with the class, you'll have a solid understanding of good OO structure and principles, and be able to apply those principles to your own work.

About the author
About the author

Allen is an internationally recognized trainer, agile-process consultant, speaker, and author. He specializes in Lean/Agile infusion and tuning, software architecture, and web-application programming using open-source toolsets. Allen's worn every hat from grunt programmer to CTO. He's built compilers, operating systems, massively scalable web applications, and mobile apps. He's written a dozen books and hundreds of magazine articles on practical programming topics, and currently blogs for Dr. Dobb's Journal (http://www.drdobbs.com/author/Allen-Holub). Allen speaks regularly at conferences, worldwide, and works for both startups and Fortune-50 companies. Contact him at: allen@holub.com, or on Twitter at @allenholub.

More from the author
Swift in Depth
Intermediate
5h 5m
11 Sep 2015
Section Introduction Transcripts
Section Introduction Transcripts

Course Overview
Hi everyone, my name is Allen Holub and welcome to my course Object-oriented Design. I have been working with Java pretty much since its inception. I also work as an independent software architect and Agile process consultant and a trainer, and I'm widely published in all of those subjects. Object-oriented programming and object-oriented design are different things. Programming is all about syntax, design is about leveraging basic design principles to write high quality effective code. Without those principles, your program can end up being an un-maintainable mess. Did you know, for example, that getters and setters aren't particularly good structure? Or that you should avoid using extends relationships whenever you can? This course then will teach you how to write industrial-strength object-oriented code. It covers the topics that the language courses and books usually skip. We'll cover essential OO-design principles and good OO structure. We'll look at anti-patterns that can get you into deep trouble. We'll look at all of the so-called SOLID principles in context, and we'll see how to test OO systems effectively. By the end of this course, you'll know how to apply OO principles to write great code. Before beginning this course though, you should know how to read Java, that said, if you know any Java-like language, C++ or C# or Swift, you should have no trouble following along. You should also know a little bit about architectural notation, UML in particular. My companion course, Picturing Architecture, covers that material. From here, you should feel comfortable diving further into design with courses on design patterns and the like. So I hope you'll join me on this journey to learn object-oriented design at Pluralsight.

Defining Behavior and State
Now let's move into the realm of the concrete. This module is going to discuss basic class definitions and how to deal with simple situations where there's no kind of inheritance involved. So let's go back to that notion of delegation that I was talking about in the last module. Here's how Java version 1 wanted you to print something out to the screen. Now this call looks simple, but actually there's a lot wrong with it. The first problem is that the Java specification actually says that you ought to be able to represent a string in Unicode. Unfortunately this line didn't work when the string was actually Unicode. So the problem is that System. out extracted the characters to print by calling a function called getBytes. Unfortunately Unicode glyphs are 16 bits wide, so getBytes just didn't work. Java's solution to that was, shall we say, suboptimal. Here's what you now have to do to print a Unicode string in Java. Now this code is just too ugly for words. It's way too complicated and it's way too long and you have to do it literally every time you want to print a string out, and that's really just not acceptable. The problem with this approach is that the designers of System. out were just not thinking about objects in the right way. One of the core concepts that we talked about in the last module is that the object that has the information should do the work. Well in this case, the string is the thing that has the information, the string has the characters that have to be printed out. So it makes much sense to ask the string that contains the characters to print them out than it does to somehow extract those characters and pass them to a string. In other words, the proper way to print a string is like this where you're asking the string to print itself, passing it the string that it needs to print to. Now let's say that we want to modify this code so that it supports Unicode. Here's the one change that we have to make, don't blink. In other words, from the outside at least we don't have to do anything. We'd have to rewrite the string class, of course, so that it would actually store a Unicode string, but once we had done that, we would be done.