Consider splitting PodLogs::BaseService into mutliple classes
From @mikolaj_wawrzyniak !25252 (comment 290032615)
I understand your concern, but this makes me look at this case for different angle. Mentioned issues can be a symptoms of a different problem. We may actually be trying to fit to much of responsibilities into single class. As single responsibility principle advise, class should have only single reason to change. One can say that the only reason to change eg:
KubernetesService
is the way we handle logs, but in fact if we can look at this in more details. Than this class will change if for example max length limits ofpod_name
,container_name
changes. Or when we change desired returned keys inSUCCESS_RETURN_KEYS
.Used
module Stepable
is a sort of framework to implement strategy pattern, I wonder maybe we can improve design ofPodLogs
services, by extracting steps into dedicated smaller classes, responsible for example for validation, data extraction, and response parsing? Such extraction can also address duplication discussed at !25252 (comment 289374758)WDYT? Of course if we will decide for such change it shouldn't be a part of this MR, but rather a follow up issue.