Why design patterns matter in Angular - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use design patterns in Angular?

Which of the following best explains why design patterns are important in Angular development?

A They replace the need for testing by ensuring code is always error-free.

B They force developers to write more code, increasing project size and complexity.

C They allow Angular to run faster by changing the framework's core behavior.

D They provide a tested way to solve common problems, making code easier to understand and maintain.

💡 Hint

Think about how patterns help teams work together and keep code clean.

Design patterns offer proven solutions that improve code clarity and maintainability, which is essential for teamwork and scaling projects.

❓ component_behavior

intermediate

Effect of Singleton pattern on Angular services

In Angular, services are often provided as singletons. What is the main benefit of this design pattern?

A It creates a new service instance for every component, isolating data completely.

B It ensures only one instance of the service exists, sharing data across components.

C It disables dependency injection, forcing manual service creation.

D It automatically reloads the service when the user navigates to a new page.

💡 Hint

Think about how data consistency is maintained across different parts of the app.

The Singleton pattern in Angular services means one shared instance, so components can access the same data and state.

❓ lifecycle

advanced

Design patterns impact on Angular component lifecycle

How can using the Observer pattern affect the lifecycle of Angular components?

A It allows components to react to data changes asynchronously, improving responsiveness and decoupling components.

B It disables Angular lifecycle hooks like ngOnInit and ngOnDestroy.

C It forces components to reload completely on every data change, reducing performance.

D It requires components to manage all data updates manually without Angular's change detection.

💡 Hint

Consider how components listen and respond to data changes over time.

The Observer pattern lets components subscribe to data streams and update only when needed, making apps more efficient and modular.

📝 Syntax

advanced

Correct use of Dependency Injection pattern in Angular

Which code snippet correctly demonstrates Dependency Injection for a service in an Angular component?

Angular

import { Component } from '@angular/core';
import { DataService } from './data.service';

@Component({
  selector: 'app-example',
  template: `<p>{{data}}</p>`
})
export class ExampleComponent {
  data: string;

  constructor(private dataService: DataService) {
    this.data = this.dataService.getData();
  }
}

A constructor(private dataService) { this.data = this.dataService.getData(); }

B constructor(dataService: DataService) { this.data = dataService.getData(); }

C constructor(private dataService: DataService) { this.data = this.dataService.getData(); }

D constructor() { this.data = DataService.getData(); }

💡 Hint

Look for correct syntax to inject and use a service instance.

Option C uses Angular's Dependency Injection correctly by declaring the service as a private parameter with its type.

🔧 Debug

expert

Identifying design pattern misuse causing memory leaks

Consider this Angular component using the Observer pattern. What is the main cause of a memory leak here?

Angular

import { Component, OnInit, OnDestroy } from '@angular/core';
import { DataService } from './data.service';
import { Subscription } from 'rxjs';

@Component({
  selector: 'app-leak',
  template: `<p>{{value}}</p>`
})
export class LeakComponent implements OnInit, OnDestroy {
  value = '';
  private subscription: Subscription;

  constructor(private dataService: DataService) {}

  ngOnInit() {
    this.subscription = this.dataService.dataStream.subscribe(val => {
      this.value = val;
    });
  }

  ngOnDestroy() {
    this.subscription.unsubscribe();
  }
}

A The subscription is not unsubscribed on component destruction, causing memory leaks.

B The component uses OnInit instead of OnDestroy lifecycle hook.

C The dataStream is not defined in the service, causing runtime errors.

D The value property is not initialized in the constructor.

💡 Hint

Think about what happens when components subscribe to streams but never stop listening.

Subscriptions must be unsubscribed when components are destroyed to avoid memory leaks from lingering observers.