A superclass should never be aware of its subclasses. Or so I thought.

I have a Filter class, which wraps a function and some of its kwargs. Some other kwargs are callable eg


you can then use the Filter object like so




You specify the callable_kwargs when constructing the filter.

Filter can have 0 or more callable_kwargs. LabelFilter inherits from Filter, and has at least one callable_kwarg: label.

I want Filter&LabelFilter (the filter constructed from the binary & operation between filters) result to be LabelFilter since it has at least one callable kwarg which is label.

At the same time, I probably don't want the Filter class to be aware of its subclasses (from software engineering considerations).

What's the appropriate way to achieve that?

(if it matters at all,the actual programming language is python, so there are no friend functions).

  • What is the conceptual result of using a binary & on two filters? Why would I do that as a user of the Filter/LabelFilter classes? – Bart van Ingen Schenau Mar 11 '20 at 11:44
  • Opinion: inheritance is an anti-pattern, it produces more problems than it solves. Use interfaces and composition. Several related peer classes being aware of each other is usually fine. – 9000 Mar 11 '20 at 22:46
  • @BartvanIngenSchenau The result is another filter, you would use the labelfilter and filter on objects eg some_label_filter(some_object,label='some_label') – yoni keren Mar 12 '20 at 13:34
  • @BartvanIngenSchenau A filter gets you a subset of somes data/object, and & operation gets you a filter for which both filters are applied. eg (filter_all_fat & filter_all_men)(some_table) would get you all fat men in the table – yoni keren Mar 12 '20 at 13:51

If a Filter can have 0 or more callable args, and LabelFilter needs at least one, maybe this condition alone breaks the inheritance?

Seems more that Filter and LabelFilter could both inherit from an abstract superclass like AbstractFilter, instead of exposing all the filter behaviour to a labelFilter when they are arguably different, as in, a LabelFilter can never be seen as a Filter since it enforces things that a filter doesn't require in the first place (a required argument in this case).

  • The way I see it, LabelFilter is a subset of Filter, pretty much the same way a Manager is a subset of Employee, a Manager has to have at least one luxury car while an Employee doesn't have to have a car at all. Can you shed a light on what's wrong with my view? A generic filter will have 0 or more callable kwargs, which is already Filter, so I'm not sure what I would have as a "generic" class and why it's needed. – yoni keren Mar 12 '20 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.