SOLID Principles for Mobile App Design Quiz Quiz

Explore your understanding of SOLID principles in mobile app development with this quiz focused on clean, maintainable, and efficient design patterns. Assess your grasp of best practices that improve code quality and scalability in mobile application projects.

1. Single Responsibility Principle

   Which of the following best demonstrates the Single Responsibility Principle in a mobile app's data model?

   1. Creating a User class that only manages user data fields and validation
   2. Adding view rendering logic directly to the User class
   3. Combining user data, authentication, and notification functions in one User class
   4. Letting the User class handle database connections and UI updates

   Explanation: The correct answer is creating a User class that only manages user data fields and validation, as this adheres to the Single Responsibility Principle by ensuring the class has one responsibility. Having authentication, notifications, or database logic violates this principle because those are separate responsibilities. Including view rendering or UI updates in the User class also breaks this principle. Keeping responsibilities focused improves maintainability.

2. Open/Closed Principle Concept

   How does the Open/Closed Principle apply when adding a new payment method to a mobile shopping app?

   1. Updating the main app class with specifics of the new payment
   2. Placing the new functionality directly in the checkout screen code
   3. Editing all existing payment classes to support the new method
   4. Extending an existing Payment interface with a new class for the new method

   Explanation: Extending an existing Payment interface with a new class allows you to add features without changing existing code, following the Open/Closed Principle. Editing existing payment classes or the main app class risks introducing bugs and increases maintenance costs. Adding payment code directly to the checkout screen mixes responsibilities and hinders scalability.

3. Liskov Substitution Principle Example

   In a mobile photo editor app, which action best follows the Liskov Substitution Principle?

   1. Using a Filter interface that allows any subclass to replace its parent without breaking the app
   2. Replacing the original Filter with an unrelated ImageCropper class
   3. Designing the base Filter class to do nothing and leaving all logic to its subclasses
   4. Creating a Filter subclass that requires extra, incompatible initialization steps

   Explanation: Liskov Substitution Principle means objects of a superclass should be replaceable with objects of a subclass without altering the proper behavior of the program. Using a Filter interface as described matches this principle. Making subclasses incompatible or unrelated to the parent, or leaving essential logic out of the base class, goes against this principle.

4. Interface Segregation Principle

   Why is splitting a mobile app's Device interface into smaller interfaces beneficial according to the Interface Segregation Principle?

   1. It increases code duplication by dividing methods
   2. It combines interface logic with business logic for speed
   3. It forces every class to implement all possible device functions
   4. It allows classes to implement only the methods they actually need

   Explanation: Splitting interfaces ensures classes only implement methods relevant to them, which is the core idea of the Interface Segregation Principle. Forcing implementation of unnecessary methods leads to bloated code and potential errors. Increasing code duplication and combining logic are not goals of this principle.

5. Dependency Inversion Principle

   Which scenario best applies the Dependency Inversion Principle in a mobile messaging app?

   1. The messaging component directly creates and manages Email and SMS objects
   2. The messaging component depends on an abstract Notification interface instead of a concrete Email class
   3. The messaging module imports hardcoded utility methods for notifications
   4. The messaging logic is tightly coupled with platform-specific APIs

   Explanation: Depending on abstractions like an interface, rather than concrete implementations, follows the Dependency Inversion Principle. Directly creating and managing specific objects or importing hardcoded methods results in tight coupling. Relying on platform-specific APIs also reduces flexibility and maintainability.

6. SRP and Maintenance

   Which result often follows when classes in a mobile app do not follow the Single Responsibility Principle?

   1. It's easier to add new features without side effects
   2. Each class remains simple and focused
   3. Code maintenance becomes harder as each class has multiple reasons to change
   4. Unit testing is straightforward for each functionality

   Explanation: When a class handles multiple responsibilities, changes in one part may unintentionally affect others, making maintenance harder. Easier feature addition, focused classes, and straightforward testing are advantages of following the principle, not violating it. Mixing responsibilities increases bugs and complexity.

7. OCP and Scalability

   When following the Open/Closed Principle, how can you make your mobile app more scalable?

   1. You always rewrite existing components to fit new requirements
   2. All new features are merged into the main application class
   3. Scalability is achieved by avoiding interfaces and inheritance
   4. You introduce new features by adding new classes or modules, not by modifying existing code

   Explanation: Scalability improves when new functionality is added through extension rather than modification. Rewriting or merging new features into the main class makes scaling and maintenance difficult. Ignoring interfaces and inheritance reduces code flexibility and contradicts the principle.

8. LSP Violation in Subclasses

   Which situation in a mobile note-taking app is a violation of the Liskov Substitution Principle?

   1. A subclass NoteAudio that crashes the app when used where a NoteText is expected
   2. A NoteText and NoteAudio class both inheriting and working seamlessly with Note
   3. A subclass NoteAudio with additional methods for audio features
   4. A NoteImage class extending Note and properly overriding necessary functions

   Explanation: If substituting a subclass for its parent causes application errors or crashes, the Liskov Substitution Principle is violated. Having additional methods or properly overridden functions does not violate it. Seamless inheritance with proper behavior is correct according to LSP.

9. ISP and Mobile UI

   In building custom UI controls for a mobile app, how does the Interface Segregation Principle help?

   1. It requires mixing UI control logic with data access methods
   2. It encourages writing large, multipurpose interfaces for flexibility
   3. It avoids forcing UI control classes to implement unnecessary event handler methods
   4. It ensures every UI control has all possible event handlers implemented

   Explanation: The principle guides developers to create smaller, focused interfaces, so UI controls only implement relevant event handlers. Having every class implement all methods or combining UI and data logic leads to bloated and less maintainable code. Large, multipurpose interfaces generally contradict the intent of ISP.

10. DIP and Flexibility

    Why does applying Dependency Inversion Principle make a mobile app easier to modify and test?

    1. It binds high-level logic to detailed, platform-specific classes
    2. It requires all modules to create their own dependencies directly
    3. It eliminates the need for interfaces or abstractions in the codebase
    4. It decouples high-level modules from low-level implementations, making substitution and mocking easier

    Explanation: This principle promotes depending on abstractions, which allows high-level modules to interact with different implementations easily and makes testing simpler. Creating dependencies directly or binding logic tightly to details hinders flexibility. Omitting interfaces or abstractions contradicts the principle entirely.