Object-Oriented Design, Design Patterns, & Software Architecture
March 9th, 2024
Retrospective
Object-Oriented Design, Design Patterns, and Software Architecture are the first three parts of a four-part collaborative course between Coursera and the University of Alberta. This course has many qualities that just don’t work in my opinion, leading to a result that is mild at best. I really, really tried to find good qualities of this course, but by the end I just couldn't.
This course prioritizes breadth over depth. Important topics are often condensed into ten-minute-long videos, where only surface level details are covered. Many of these details are reiterated to the point where dialog feels more redundant than reinforcing. I don’t have enough digits on my hands and feet to count how many times “XYZ will make your code more reusable, flexible, and maintainable” was said ad nauseam. These shallow lectures and lack of hands-on work left me extremely unsatisfied.
What I Learned
Because this course is composed of three sub-courses, I will discuss what I learned from each course separately.
Object-Oriented Design
Object-Oriented Design (OOD) covers some of the team-based, non-programming skills related to software development. For outsider to the discipline, the course provides insight into how software development teams work together to design software systems in a business environment. Design tools like UML diagrams are covered. These diagrams are used to plan out software systems before any implementation work is done. I learned Mermaid JS, a UML diagramming tool, so I could practice making these diagrams. The principles of object-oriented programming: abstraction, encapsulation, inheritance, and polymorphism, are covered extensively. These principles, along with coupling and cohesion, are introduced in Object-Oriented Design and are repeatedly applied in later parts of the course.
Design Patterns
Design Patterns was by far the most interesting and useful of the three parts of the course. Creational, structural, and behavioral design patterns are discussed in sufficient detail. These design patterns are extremely useful to be aware of when working with the object-oriented programming paradigm. Design Patterns covers the problems associated with each design pattern, and how those problems can be addressed by using them in conjunction with other design patterns. This emphasizes how design patterns are not mutually exclusive and can be used in combination to design more effective software systems. It’s also interesting to consider how these design patterns arise from different OOD principles like the open/closed principle, dependency inversion, etc. Anti-patterns are covered, but in lesser detail.
Even still, Design Patterns has its flaws. It's odd that they discussed the design principles after describing design patterns. Since many design patterns naturally arise as solutions to object-oriented design principles, I think it would have been useful to know these principles beforehand to give better context for the design patterns. Additionally, this course only covers around half of the design patterns outlined in the gang-of-four book. It’s frusturating that they exclude the other ten or so design patterns, and it felt like the course was cut short right when the content was starting to get interesting. Like with most aspects of this course, Design Patterns settles for good enough.
Software Architecture
Software Architecture’s main purpose is to look at different system architectures, and assess their use cases, advantages, and disadvantages. The most interesting part of this course, in my opinion, was seeing different architectures that I was aware of in an abstract sense sorted into concrete categories. It was one of the only parts in this three-part course where anything really “clicked” for me. It gave me a whole new perspective on the design choices for lots of software and programs I’m already familiar with.
This part of the course involves absolutely zero programming, which makes learning through doing impossible. There is a lot of jargon thrown around carelessly, and the second half of Software Architecture feels more like a business course than a computer science course. However, this isn’t the worst thing, as it’s important to understand software in the context of a business. One knows that it’s important to identify quality attributes so you can pivot strategies and not move the project goalposts too far, resulting in having to circle back later. These topics have lots of moving parts and I don’t expect the instructors to be giving me their 110%...
Dislikes
Someone decided that the best teacher would be a theater major reading from a teleprompter. I'd prefer to have been taught by someone who knows what they're saying, but I guess we can't always have what we want. Listening to someone read from a script with feigned enthusiams for hours is a soul-crushing experience, and is one of my main arguments for why this course fails to teach effectively. Courses are elevated from good to great when they are taught by someone that deeply understands the topics they are teaching. This gives the course several qualities. Most importantly, the instructor can emphasize the importance of ideas and elaborate on them. The failure of this course's lecturer to extract meaning from the words they are saying is what prevents this course from being engaging. This quote from the GitHub user Ahsatan sums the matter up best in my opinion:
"The tedium of watching somebody who clearly doesn't care about the topic and can't pronounce 'Java' nor 'attributes' was infuriating. Passion is so valuable towards engaging your audience and this class falls flat after the previous courses I’ve taken."
Of course I don’t blame the person reading from the script, they’re just doing their job. I blame the course's creators for (1) making the course read verbatim from a script and (2) choosing someone inexperienced in software design.
There are, on occasion, times where what is being said makes no sense. This is the result of typos in the script, and the script reader having no idea what they are saying. I liken it to how a generative AI can halluciante utter nonsense with complete confidence.
One thing this course loves to throw around is similes. This design pattern is like an automatic coffee maker. This software architecture is like a water treatment facility. This separation of concerns is like the students and teachers at a school. I agree that comparisons are a great way to introduce students to a new concept, since they can compare it to something they are already familiar with. The problem arises when a student becomes reliant on that comparison to understand the new concept. It reminds me of how circuits are taught to first-year engineering students. Because electricity can be abstract and difficult for lots of people to understand, electrical components and circuit properties are introduced using fluid flow comparisons. For example, voltage is like the pressure differential in a pipe, and therefore batteries are like pumps that create a voltage differential in the circuit. Object-Oriented Design, Design Patterns, and Software Architecture are the electrical engineering course that never abandons these analogies for a more fundamental understanding of electricity and circuits, if you get what I mean.
Suggestions for Students
Honestly, I want to say don’t bother with this course. If you do bother, I suggest that you follow the free track and take good, thorough notes on the lectures. Don’t bother with the capstone project, as the documentation is outdated and the work in Android Studio is beyond the scope of the course.
Key Takeaways
- Diagramming a software system makes spotting flaws and inconsistencies in that software system much easier.
- Design patterns are conventionalized program structures to solve common design issues.
- The quality of software architecture is determined by how well it addresses the requirements for a specific use case in a specific environment, and therefore software architecture cannot be labelled as strictly “good” or “bad” without context.
Table of Contents