It always starts the same way.<\/p>\n\n\n\n
You just need a small script<\/strong>.<\/p>\n\n\n\n In my case, it was \u201cjust\u201d a helper to get a Salesforce data migration over the line. I needed to switch off flows and validation rules, loosen some picklists, load data, then switch everything back on.<\/p>\n\n\n\n So I did what most of us do: I opened a file and started writing functions.<\/p>\n\n\n\n The script worked. It passed a quick test. I moved on.<\/p>\n\n\n\n Weeks later, I had to run another migration, with more objects and more \u201cthings\u201d to toggle. That\u2019s when the cracks showed. The script was no longer \u201csmall\u201d \u2014 and it definitely wasn\u2019t easy to change safely.<\/p>\n\n\n\n That experience is why my next \u201csmall script\u201d now starts with objects, not functions<\/strong>.<\/p>\n\n\n\n This post walks through that shift using real code: how I refactored a procedural Salesforce migration helper into an object\u2011oriented design built around House, Room, and Switch<\/strong> \u2014 and why that\u2019s more than just clever naming.<\/p>\n\n\n\n My original approach in There\u2019s nothing \u201cwrong\u201d with this in isolation. It:<\/p>\n\n\n\n The problem wasn\u2019t correctness; it was shape<\/strong>. Every time I added a new type of thing to control (validation rules, picklists), I ended up copying the same pattern:<\/p>\n\n\n\n The more functions I added, the harder it was to see the higher\u2011level intent:<\/p>\n\n\n\n \u201cFor this object, switch off everything that could interfere, migrate, then restore exactly what should be on.\u201d<\/p>\n<\/blockquote>\n\n\n\n That\u2019s when I stopped and asked: \u201cIf I rewrote this from scratch, pretending it\u2019s not \u2018just\u2019 a script, what would it look like?\u201d<\/p>\n\n\n\n When I described the process out loud, it sounded nothing like my code:<\/p>\n\n\n\n The more I leaned into that image, the clearer the structure became:<\/p>\n\n\n\n So I rewrote the script around those objects.<\/p>\n\n\n\n Here\u2019s the high\u2011level orchestration now:<\/p>\n\n\n And the migration flow becomes:<\/p>\n\n\n Same job as before \u2014 but now the top\u2011level code is telling the story directly, not drowning in detail.<\/p>\n\n\n\n The power comes from the OO concepts under the hood: abstraction, encapsulation, inheritance, polymorphism<\/strong>. Here\u2019s how they show up in this very concrete problem.<\/p>\n\n\n\n Abstraction<\/strong> is about describing what you can do, without exposing how it\u2019s done.<\/p>\n\n\n\n At the heart of this design are two abstract base classes:<\/p>\n\n\n The abstractions here are:<\/p>\n\n\n\n The main script doesn\u2019t need to know:<\/p>\n\n\n\n It only needs to know:<\/p>\n\n\n That\u2019s abstraction: the calling code deals in concepts<\/strong>, not implementation details.<\/p>\n\n\n\n Encapsulation<\/strong> means bundling data and behaviour into self\u2011contained units.<\/p>\n\n\n\n Take Everything needed to manage a single flow lives in this class:<\/p>\n\n\n\n No other part of the system builds CLI commands or parses flow metadata. Outside code says:<\/p>\n\n\n This is where OO stops being theory and starts being practical:<\/p>\n\n\n\n Encapsulation keeps the messy bits in small, named boxes.<\/p>\n\n\n\n Inheritance<\/strong> lets you define a common shape once and have specific kinds of things follow that shape.<\/p>\n\n\n\n Here:<\/p>\n\n\n\n This guarantees:<\/p>\n\n\n\n So when you go to add the next \u201csmall thing\u201d \u2014 say, a new kind of metadata you want to toggle \u2014 you\u2019re not guessing how to shape it. You inherit from Inheritance here isn\u2019t about sharing random helper methods; it\u2019s about sharing a contract<\/strong>.<\/p>\n\n\n\n Polymorphism<\/strong> is what lets you call the same method ( The But That\u2019s why adding a new type of switchable thing doesn\u2019t change the migration workflow. You:<\/p>\n\n\n\n The loops in After going through this, I don\u2019t start migration tooling with functions anymore. Even if it feels like \u201cjust a script,\u201d I pause and ask:<\/p>\n\n\n\n In this case, those nouns were House<\/strong>, Room<\/strong>, and Switch<\/strong>, backed by solid OO concepts:<\/p>\n\n\n\n The end result isn\u2019t just \u201cmore OO.\u201d It\u2019s code I can:<\/p>\n\n\n\n That\u2019s why my next \u201csmall script\u201d starts with objects, not functions. It\u2019s not about impressing anyone with design patterns; it\u2019s about not dreading the next time I have to touch the code.<\/p>\n\n\n\n And if you\u2019ve ever opened an old \u201cquick script\u201d and wondered \u201cwhat on earth was I thinking?\u201d<\/strong>, that shift might be worth trying in your next one, too.<\/p>\n","protected":false},"excerpt":{"rendered":" It always starts the same way. You just need a small script. In my case, it was \u201cjust\u201d a helper...<\/p>\n","protected":false},"author":1,"featured_media":96,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-95","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-productivity-without-the-hype"],"yoast_head":"\n\n
fetch_active_flows(object_id)<\/code><\/li>\n\n\n\ndeactivate_flow_trigger(object_id)<\/code><\/li>\n\n\n\nactivate_flow_trigger(object_id)<\/code><\/li>\n\n\n\nThe First Version: A Script That Grew Fangs<\/h2>\n\n\n\n
oldflow.py<\/code> was purely procedural. For example:<\/p>\n\n\n\ndef deactivate_flow_trigger(object_id):\n """\n Deactivate all active flow triggers related to the object\n """\n cfv = fetch_active(object_id)\n for record in cfv['records']:\n\n flow_id = record['Id']\n latest_version_id = record['LatestVersionId']\n api_name = record['ApiName']\n is_active = record['IsActive']\n\n print(f"Updating...Flow ID: {flow_id}, Latest Version ID: {latest_version_id}, API Name: {api_name}, IsActive: {is_active}")\n update_flowdefinition(latest_version_id,0)\n\ndef activate_flow_trigger(object_id):\n """\n Activate all flow triggers related to the object from the baseline that should be active\n """\n should_active = fetch_should_active(object_id)\n curr_inactive = fetch_inactive(object_id)\n for record in curr_inactive['records']:\n\n flow_id = record['Id']\n latest_version_id = record['LatestVersionId']\n api_name = record['ApiName']\n is_active = record['IsActive']\n curr_version_number = record['VersionNumber']\n\n print(f"Looping Inactive Flow ID: {flow_id}, Latest Version ID: {latest_version_id}, API Name: {api_name}, IsActive: {is_active}, Current Vn:{curr_version_number}")\n\n for lkp in should_active:\n if lkp['Id'] == flow_id:\n update_flowdefinition(latest_version_id, curr_version_number)\n<\/pre><\/div>\n\n\n\n
\n
\n
The Mental Shift: Think in Objects, Not Steps<\/h2>\n\n\n\n
\n
\n
The New Shape: House, Rooms, Switches<\/h2>\n\n\n\n
\nfrom data import DataService\nfrom flow import FlowRoom\nfrom validationrule import ValidationRuleRoom\nfrom picklist.picklist import PicklistRoom\n\nclass House():\n def __init__(self, name):\n self.Name = name\n self.Id = self.get_object_id()\n self.Rooms = self.create_rooms()\n\n def get_object_id(self):\n return DataService.get_object(self.Name)\n\n def create_rooms(self):\n rooms_dict = {}\n flow_room = FlowRoom(self.Id)\n rooms_dict["Flow"] = flow_room\n validation_rule_room = ValidationRuleRoom(self.Id)\n rooms_dict["ValidationRule"] = validation_rule_room\n picklist_room = PicklistRoom(self.Name) \n rooms_dict["Picklist"] = picklist_room\n return rooms_dict\n\n def visit(self):\n sorted_keys = sorted(self.Rooms.keys())\n for key in sorted_keys:\n room = self.Rooms[key]\n room.enter()\n\n def depart(self):\n sorted_keys = sorted(self.Rooms.keys())\n for key in sorted_keys:\n room = self.Rooms[key]\n room.exit()\n<\/pre><\/div>\n\n\n\nif __name__ == "__main__":\n house = House("Account")\n\n # 1. Before migration: turn off flows, rules, picklists\n house.visit()\n\n # ... run migration ...\n\n # 2. After migration: restore everything\n house.depart()\n<\/pre><\/div>\n\n\nAbstraction: Separating \u201cWhat\u201d From \u201cHow\u201d<\/h2>\n\n\n\n
\nfrom abc import ABC, abstractmethod\n\nclass Room(ABC):\n def __init__(self, obj_id):\n self.obj_id = obj_id\n\n @abstractmethod\n def get_switches():\n return []\n\n @abstractmethod\n def enter():\n pass\n\n @abstractmethod\n def exit():\n pass\n\nclass Switch(ABC):\n def __init__(self, Id, Name, InitialState):\n self.Id = Id\n self.Name = Name\n self.InitialState = InitialState\n\n @abstractmethod\n def on(self):\n pass\n\n @abstractmethod\n def off(self):\n pass\n<\/pre><\/div>\n\n\n
\n
Switch<\/code> is \u201csomething that can be turned on or off.\u201d<\/li>\n\n\n\nRoom<\/code> is \u201csomething that can be entered (prepare) and exited (restore) for a given object.\u201d<\/li>\n<\/ul>\n\n\n\n\n
\nroom.enter() # get ready (e.g., turn things off)\nroom.exit() # put it back (e.g., turn things on)\n<\/pre><\/div>\n\n\n
Encapsulation: Keeping the Gory Details Local<\/h2>\n\n\n\n
FlowSwitch<\/code>:<\/p>\n\n\n\nimport subprocess, json, os\nfrom interfaces import Switch, Room\n\nclass FlowSwitch(Switch):\n def __init__(self, Id, Name, InitialState, CurrentState, LatestVersionId, VersionNumber):\n super().__init__(Id, Name, InitialState)\n self.CurrentState = CurrentState\n self.LatestVersionId = LatestVersionId\n self.VersionNumber = VersionNumber\n\n def on(self):\n if self.InitialState:\n if self.CurrentState == False:\n self.update(self.VersionNumber)\n print(f"FlowSwitch-{self.Name} turned on")\n else:\n print(f"FlowSwitch-{self.Name} already on")\n else:\n print(f"FlowSwitch-{self.Name} shouldn't be on - update skipped")\n\n\n def off(self):\n if(self.CurrentState):\n self.update(0)\n print(f"FlowSwitch-{self.Name} turned off")\n else:\n print(f"FlowSwitch-{self.Name} already off")\n\n def update(self, version_number):\n """\n Update a flow definition record with a version number. If input vn is zero, it will be updated as inactive\n If input vn > 0, it will be updated as active\n """\n try:\n query_res = subprocess.run(\n [\n "sf", \n "data", \n "query", \n "--query",\n f"select Id from FlowDefinition where LatestVersionId='{self.LatestVersionId}'",\n "-t",\n "--json",\n ], \n capture_output=True, \n text=True, \n check=True\n )\n tmp = json.loads(query_res.stdout)\n flow_id = tmp['result']['records'][0]['Id']\n\n command = [\n "sf", \n "data", \n "update",\n "record",\n "-t",\n "-s",\n "FlowDefinition",\n "-i",\n f"{flow_id}",\n "-v",\n f"Metadata='{{\\"activeVersionNumber\\":{version_number}}}'"\n ]\n print(f"Command:{command}")\n #result = subprocess.run(command, capture_output=True, text=True, check=True)\n print(f"'{self.LatestVersionId}' successfully updated to {version_number}")\n except subprocess.CalledProcessError as e:\n print(f"Error updating flow: {e.stderr}")\n<\/pre><\/div>\n\n\n\n
on()<\/code>, off()<\/code>, update()<\/code>.<\/li>\n<\/ul>\n\n\n\n\nswitch.off() # for pre\u2011migration\nswitch.on() # for post\u2011migration\n<\/pre><\/div>\n\n\n
\n
FlowSwitch.update()<\/code> in one place.<\/li>\n\n\n\nInheritance: Sharing the Structure, Not the Hacks<\/h2>\n\n\n\n
\n
FlowSwitch<\/code> inherits from Switch<\/code>.<\/li>\n\n\n\nFlowRoom<\/code> inherits from Room<\/code>.<\/li>\n<\/ul>\n\n\n\nclass FlowSwitch(Switch):\n # Must provide on() and off()\n ...\n\nclass FlowRoom(Room):\n def __init__(self, obj_id):\n super().__init__(obj_id)\n self.switches = self.get_switches()\n ...\n<\/pre><\/div>\n\n\n
\n
Id<\/code>, Name<\/code>, InitialState<\/code>.<\/li>\n\n\n\non()<\/code> and off()<\/code>.<\/li>\n\n\n\nget_switches()<\/code>, enter()<\/code>, and exit()<\/code>.<\/li>\n<\/ul>\n\n\n\nSwitch<\/code> and Room<\/code> and follow the same pattern.<\/p>\n\n\n\nPolymorphism: One Loop, Many Implementations<\/h2>\n\n\n\n
enter<\/code>, exit<\/code>) on different object types and have each do what\u2019s appropriate.<\/p>\n\n\n\nHouse<\/code> class leans on this heavily:<\/p>\n\n\n\ndef visit(self):\n sorted_keys = sorted(self.Rooms.keys())\n for key in sorted_keys:\n room = self.Rooms[key]\n room.enter()\n\ndef depart(self):\n sorted_keys = sorted(self.Rooms.keys())\n for key in sorted_keys:\n room = self.Rooms[key]\n room.exit()\n<\/pre><\/div>\n\n\n
FlowRoom<\/code>, ValidationRuleRoom<\/code>, and PicklistRoom<\/code> all implement enter()<\/code> and exit()<\/code> in their own way:<\/p>\n\n\n\n\n
FlowRoom.enter()<\/code> uses FlowSwitch.off()<\/code> to deactivate flows.<\/li>\n\n\n\nValidationRuleRoom.enter()<\/code> deactivates validation rules.<\/li>\n\n\n\nPicklistRoom.enter()<\/code> relaxes picklists.<\/li>\n<\/ul>\n\n\n\nHouse<\/code> doesn\u2019t know (or care) which is which. It just walks rooms and calls enter()<\/code>\/exit()<\/code>.<\/p>\n\n\n\n\n
NewThingSwitch<\/code> and NewThingRoom<\/code> subclasses.<\/li>\n\n\n\nNewThingRoom<\/code> in create_rooms()<\/code>.<\/li>\n<\/ol>\n\n\n\nvisit()<\/code> and depart()<\/code> remain untouched.<\/p>\n\n\n\nWhy My Next \u201cSmall Script\u201d Starts with Objects<\/h2>\n\n\n\n
\n
\n
for room in Rooms<\/code>) drives very different behaviours.<\/li>\n<\/ul>\n\n\n\n\n