From 2522fb676c285d8f9efe93b7a0426a5b9d3597e6 Mon Sep 17 00:00:00 2001
From: cliffmccarthy <16453869+cliffmccarthy@users.noreply.github.com>
Date: Thu, 13 Nov 2025 07:40:22 -0600
Subject: [PATCH] docs: Remove section about use of objects

---
 doc/source/overview.rst | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/doc/source/overview.rst b/doc/source/overview.rst
index 483bd818..4b4a044f 100644
--- a/doc/source/overview.rst
+++ b/doc/source/overview.rst
@@ -342,28 +342,3 @@ of building a general-purpose container image.
 Operations that start services for systemd-based deployments should
 only be called from the ``activate_impl()`` methods.  These methods
 will not be called in non-systemd container environments.
-
-Deployer objects
-~~~~~~~~~~~~~~~~
-
-One might ask why the deployers are implemented as object classes, as
-opposed to callable functions or the like.  There are various reasons
-why objects are a good fit for the deployment process.
-
-1. Objects provide a way to organize the install, configure, and
-deploy operations for each component that is installed, supporting a
-"driver" type of pattern.  This could be implemented in other ways
-without objects, such as function jump tables, but objects provide a
-clean and formalized way to do essentially the same thing.
-
-2. Class inheritance provides a natural way to define
-component-specific operations for the various stages of deployment, by
-overriding the no-op stub methods in the base class.  The base class
-handles policy decisions about which stages are to be executed,
-ensuring consistent handling of the stages in a central location.
-
-3. Some of the components track state between stages, basing decisions
-like whether to restart a service on whether the software or
-configuration of that service was changed in an earlier stage.
-Keeping track of state between method calls is an ideal use case for
-objects.