CODEWITHSUNDEEP
oopinheritancelanguage-agnostic
bgusach
bgusach

Reputation: 15175

OOP: class inheritance to add just one property vs constructor argument

I'm new to OOP and I'm in the following situation: I have something like a report "Engine" that is used for several reports, the only thing needed is the path of a config file.

I'll code in Python, but this is an agnostic question.So, I have the following two approaches

A) class ReportEngine is an abstract class that has everything needed BUT the path for the config file. This way you just have to instantiate the ReportX class

enter image description here

class ReportEngine(object):
    ...

class Report1(ReportEngine):
    _config_path = '...'

class Report2(ReportEngine):
    _config_path = '...'

report_1 = Report1()

B) class ReportEngine can be instantiated passing the config file path

class ReportEngine(object):
    def __init__(self, config_path):
        self._config_path = config_path
    ...

report_1 = ReportEngine(config_path="/files/...")

Which approach is the right one? In case it matters, the report object would be inserted in another class, using composition.

Upvotes: 0

Views: 157

Answers (3)

Desty
Desty

Reputation: 2776

Generally spoken, put everything which every Report has, in the superclass. Put specific things in the subclasses.

So in your case, put the _config_path in the superclass ReportEngine like in B) (since every Report has a _config_path), but instanciate specific Reports like in A), whereas every Report can set its own path.

I don't know Python, but did a quick search for the proper syntax for Python 3.0+, I hope it makes sense:

class ReportEngine(object):
    def __init__(self, config_path):
        self._config_path = config_path

    def printPath(self):
        print self._config_path
    ...

class Report1(ReportEngine):
    def __init__(self):
        super().__init__('/files/report1/...')

Then a

reportObj = Report1()
reportObj.printPath()

should print

'/files/report1/...'

Upvotes: 1

davioooh
davioooh

Reputation: 24686

IMHO the A) approach is better if you need to implement report engines that are different from each other. If your reports are populated using different logic, follow this approach.

But if the only difference among your report engines is the _config_path i think that B) approach is the right one for you. Obviosly, this way you'll have a shared logic to build every report, regardless the report type.

Upvotes: 2

matino
matino

Reputation: 17725

Basically the main difference is that approach A is more flexible than B(not mutual change in one report does not influence other reports), while B is simpler and clearer (shows exactly where the difference is) but a change affecting one report type would require more work. If you are pretty sure the reports won't change in time - go with B, if you feel like the differences will not be common in the future - go with A.

Upvotes: 0

Related Questions