Intro to OO

Reading Only

The goal here is to introduce you to Object Oriented terminology so you can begin your career-long exploration of Object Oriented Design and Programming. There's a lot of nuance with OO; there are tradeoffs and endless opinions out there. I can't teach you everything you need to know, but I'll give you the foundation and vocabulary you need to explore the world of OO on your own and form your own opinions.

This course assumes you have basic knowledge of defining classes and instantiating objects. I recommend going through the Classes and Methods courses if you don't. Let's get started!

You don't just stumble into OO software; you design it. The design process involves defining classes, determining how they'll be instantiated, and how they'll interact with each other. Merely using an OOP language and creating custom classes doesn't guarantee great software.

There is no perfect design for OO, just varying degrees of correctness. The choices you make will involve tradeoffs that others may disagree with. It's not all ambiguous, though; there are core principles that "good" OO design has in common. To get there, our OO process needs to include:

Object-Oriented Analysis:

You must understand the domain and problem space you're working in. You go through the process of understanding functional and non-functional requirements, turning them into use cases along the way.

Object-Oriented Design:

This is where you start defining and describing objects. You'll map out what "key" objects are needed and how they interact. We don't care about the nitty-gritty details of the object, but we will need to consider its responsibilities. This is the cohesive collection of data and behavior it encapsulates. You start asking yourself questions like:

• "Should the object validate the data passed in or trust it to be pre-validated?"
• "Should this object be responsible for executing its own SOQL or be given all the data it needs?"
• "What types of exceptions should this object be able to handle, and which should it delegate to its caller?"

A "good" OO design encapsulates relevant data and behavior but only reveals this data and behavior to other objects when pertinent. When it reveals its information, it does so through a layer of abstraction by providing an interface to prevent an object's inner workings from being revealed.

Object-Oriented Programming:

Here, you can worry about the nitty-gritty details. You'll convert your design into testable and maintainable code. We'll use inheritance to extend code for reuse. We'll use encapsulation to bundle relative information and hide implementation details. We'll use polymorphism to resolve dependencies at runtime. If none of that made sense, you're in the right place. We'll break down these ideas and have you write code to make sense of them.

Quality and Complexity

But before we do, we need to understand the problem OOP is trying to solve. We'll set the context by first understanding software quality and complexity.