Mental model
A design pattern is a named solution to a problem that keeps showing up in software. If you have hit the problem before, the pattern is a shortcut to a working design. If the problem is new to you, the pattern name is how you ask about it (“I need Observer here” is faster than describing the whole shape).
Cisco objective 1.6 (CCNAAUTO 200-901) asks you to explain the advantages of two patterns: MVC and Observer. You do not implement them on the exam; you recognise them and say what they are for.
MVC: Model, View, Controller
MVC separates an application into three jobs:
| Piece | Job | Example in a network dashboard |
|---|---|---|
| Model | Hold the data; know nothing about how it is displayed | List of switches with their uptime, loaded from an API |
| View | Render the data; know nothing about where it came from | HTML table that shows switch rows |
| Controller | Receive user input; tell the Model to change and the View to re-render | Click handler for “refresh” that fetches switches and updates the table |
Why bother
- Change the View without touching the Model. Switch from HTML to a terminal UI; the Model stays the same.
- Change the Model without touching the View. Switch the data source from Meraki to Catalyst Center; the HTML table does not care.
- Test each piece in isolation. Unit tests on the Model do not need a browser.
Where you have already seen MVC
- Django and Rails (with slight naming differences — Rails calls it MVC, Django calls it MTV).
- Most GUI frameworks (Qt, iOS UIKit, Android).
- Cisco Catalyst Center and Meraki dashboards are built this way internally.
Smaller variants worth knowing by name
- MVP (Model-View-Presenter) — like MVC but the Presenter does more of the formatting work. Popular in older desktop apps.
- MVVM (Model-View-ViewModel) — like MVP but the ViewModel exposes its data in a way the View can bind to automatically. Dominant in modern frontend frameworks (Vue, Angular, WPF).
Not on 200-901; just so you recognise them when they come up.
Observer: subscribe to events
Observer lets one object (the Subject) notify many other objects (Observers) when its state changes. The Subject does not need to know who its Observers are; they register and unregister themselves.
Shape
┌──────────┐ notify() ┌────────────┐
│ │ ────────────────────────▶ │ Observer A │
│ Subject │ ────────────────────────▶ │ Observer B │
│ │ ────────────────────────▶ │ Observer C │
└──────────┘ └────────────┘
▲
│ subscribe(observer)
Example: watching a switch go up/down
class SwitchMonitor: # Subject
def __init__(self):
self._observers = []
def subscribe(self, obs):
self._observers.append(obs)
def _notify(self, event):
for obs in self._observers:
obs.on_event(event)
def check(self, switch):
if not switch.ping():
self._notify({"host": switch.host, "status": "down"})
class SlackAlerter: # Observer
def on_event(self, event):
print(f"[slack] {event['host']} is {event['status']}")
class SmsAlerter: # Observer
def on_event(self, event):
print(f"[sms] {event['host']} is {event['status']}")
m = SwitchMonitor()
m.subscribe(SlackAlerter())
m.subscribe(SmsAlerter())
m.check(some_switch) # fires both alerters if the switch is down
Why bother
- Decoupling.
SwitchMonitordoes not know about Slack or SMS. You can add email, PagerDuty or a webhook alerter without touching the monitor. - Many listeners. Multiple interested parties get notified from one place.
- Removable. Observers can
unsubscribewhen they no longer care.
Where you have already seen Observer
- GUI event handlers (click, keypress) are observers subscribed to a widget.
- Webhooks (Cisco objective 2.2) are a network version: the Subject (API provider)
POSTs to every subscribed URL when an event happens. - Pub/sub systems (Kafka, RabbitMQ, SNS/SQS, syslog subscribers) are Observer at platform scale.
- gNMI subscriptions (streaming telemetry from Catalyst switches) are Observer at network scale: the device publishes, your collector subscribes.
- Python’s
loggingmodule: handlers (file, console, syslog) are observers of a logger.
MVC vs Observer in one line
- MVC separates where code lives (data layer, UI layer, control layer).
- Observer separates who knows about whom (one source, many anonymous listeners).
They are orthogonal. A real app often uses both: the Model in an MVC app notifies the View via Observer when it changes.
The #1 mistake
Applying a pattern because it has a name. Patterns are useful when the problem they solve shows up. Shoehorning MVC into a 100-line script because MVC “is the right way” produces more boilerplate than value. Rule: feel the pain first, then reach for the pattern.
FAQ
Are there other patterns I need for 200-901? No. The exam explicitly names MVC and Observer. Others (Singleton, Factory, Strategy, Adapter) are useful career knowledge but not on the blueprint.
Which is more common in network automation? Observer, by a wide margin, because of webhooks, pub/sub telemetry, and event handlers in UI tools. MVC is more common in network management applications you consume (Catalyst Center, Meraki Dashboard) rather than scripts you write.
Is pub/sub the same as Observer? Pub/sub is Observer with a middleman (a broker like Kafka or Redis). The Publisher and Subscribers do not know each other at all; the broker holds the subscriptions. Pure Observer typically has the Subject hold its own subscriber list.
Where did the Gang of Four come from? The 1994 book “Design Patterns” by Gamma, Helm, Johnson and Vlissides catalogued 23 reusable patterns. Observer is one; MVC is older and sometimes classified separately. The book is the origin of calling these solutions “patterns” at all.
Can I see MVC and Observer in a real Cisco API? The Cisco DNA Center / Catalyst Center web UI is MVC internally. The webhook feature of Webex (and of GitHub, Slack, PagerDuty, etc.) is Observer: you subscribe your URL and get notified when events happen.