Software Architecture

Vasiliy Zukanov
A free video tutorial from Vasiliy Zukanov
Professional Android developer, Blogger, Educator
4.7 instructor rating • 7 courses • 26,198 students

Learn more from the full course

Android Architecture Masterclass

Embrace clean design and architecture in your Android applications

07:05:31 of on-demand video • Updated August 2020

  • Learn the most important aspects of Android architecture
  • Decouple user interface logic in your codebase using MVC pattern
  • Employ Dependency Injection to follow Separation of Concerns principle
  • Discover the real roles of Activities and Fragments in Android applications
  • Understand Single-Activity vs. Multi-Activity trade-offs
  • Use clean packages structure to reflect the business domain of your application
  • Avoid "Spaghetti Code" and "God Classes"
English I'm pretty sure that you have heard the term software architecture many times in the past, but have you ever heard its definition? Do you know what distinguishes architecture from other software development activities? Have you ever wondered why it gets so much attention? To explain you what architecture is and what it isn't, I'd like to quote several prominent members of the software community, and then see if we can find a common denominator among their opinions. The first one is Grady Booch. He's best known for his work in the field of object oriented design, and invention of so-called Booch notation. You might have not heard of Booch notation before, but you see it all the time, because it became a part of Unified Modeling Language, UML, in short. Grady Booch said the following: "Architecture represents the significant design decisions "that shape a system, where significant is measured "by the cost of change." Note that I highlighted the word change. You will understand why in a moment. The next prominent member of software community that I'd like to quote, is Martin Fowler. He's best know as the author of the book titled Refactoring Improving the Design of Existing Code. So, Fowler says, "Architecture is the set of decisions "that are hard to change." And again note the highlighted word. Juval Lowy is the president of a company called IDesign, which conducts professional trainings for software architects. Juval is not as famous as either Grady Booch or Martin Fowler, but he is very well respected among developers who know him. Juval Lowy claims that, "It if doesn't change, "there is no block the encapsulates "it on architecture diagram." And just like before, change appears to be a major factor in his view of software architecture. In fact, Juval says that if something doesn't change, it is, by definition, not a part of applications architecture. All in all, you can see that these three prominent figures in software community agree that architecture has everything do do with change. I will define it more precisely in a moment, but let me proactively address one important point. In many discussions of software architecture, it is being seen through a prism of various third-party frameworks and libraries. Therefore, a natural question will be, what's the role of frameworks and libraries in architecture? To answer this question, I'll quote another prominent figure in software community, Robert "Uncle Bob" Martin. He's the one who popularized "clean" adjective in software, and he's best known for his books Clean Code and Clean Architecture. So, Robert Martin claims that "Architectures are not "(or should not) be about frameworks." And since frameworks are complex libraries, we can extrapolate this claim to all the third-party libraries in general. I completely agree with Robert Martin on this. Various frameworks and libraries can't make your architecture better, but they can definitely make it worse if you let your code become too coupled to them. You won't see me using fancy libraries in this course, because my goal is to show you the pure Android applications architecture in its most fundamental form. Now let's summarize what we discussed and give a proper definition to software architecture. Architecture is risk management decisions that you make in anticipation of inevitable change of system's requirements. In other words, good architecture should make the system more resilient to change. Good architecture is a result of many educated trade-offs because you can't prepare for all the changes that can theoretically happen. For example, you can't prepare for a company pivoting to a different business model. Therefore you need to choose some specific scenarios that you optimize your application for. Software architecture should be independent of third-party frameworks and libraries, as simple as that. Architecture manifests itself by severely affecting the costs of software development and maintenance. Note that cost is proportional to effort, so good architecture allows you to go fast. And that's the most important point. However, it's not always easy to relate to high level project considerations. Therefore, let's talk about you for a moment. What's in architecture for you? Well it's simply much easier and much more fun to work in code bases that have proper architecture. Good architecture means that you won't need to look for things. The code will be readable and intuitive. The functionality will be divided into small, independent chunks that are easy to reason about and modify. At the end of the day, working in a code base with proper architecture makes you productive and less stressed. It makes you happier as a developer, and that's simply huge.