[Tutor] What's the correct way to define/access methods of a member variable in a class pointing to an object?

khalil zakaria Zemmoura zemmoura.khalil at gmail.com
Sat Sep 3 07:42:31 EDT 2016


Hi,

Composition is a technique that allows you to express the 'has a'
relationship between your object.

I'm not a specialist of the OOP but I can see some issues in the model that
you expose in your mail.

Encapsulation and abstraction are all about designing an API. It allows you
to expose simple usable API'S and hiding all the complexity from the user
of your classes.

If a user have to use your classes in inheritance or composition, he/she
doesn't have to worry about the internal details.

Wrapping methods of class Foo is a good thing I think.

In the case you don't use encapsulation:

If Foo is used in Bar, Bat, Baf and after that, the three classes are used
anywhere in your code, if you change the API of Foo, you'll end up making
changes in all the places where Foo is mentioned! and that's tedious

Now, if you use encapsulation

The same scenario is not a big deal anymore because you'll end up making
less changes than before. That's makes the life easier

Abstracting irrelevant details also makes the process of developing easier
because you don't have to deal with low level of details to make a code
working and helps you to reason about your code in a more efficient way.

That techniques lower the level of complexity you have to deal with.

I hope that helps a little bit.

Regards.

Le 3 sept. 2016 10:24, "Sharad Singla" <sharad1087 at gmail.com> a écrit :

> Hi Pythonistas
>
> What's the correct way to define/access methods of a member variable in a
> class pointing to an object?
>
> For example, I have a class Foo that has a method foo_method:
>
> class Foo:
>     def foo_method(self):
>         return 'bar'
>
> Now, in another class Bar, I'd like to store an object to this class (I do
> not want Bar to inherit Foo).
>
> What is the correct/recommended way to define class Bar?
>
> class Bar:
>     def __init__(self):
>         self.foo = Foo()
> # OR
> class Bar:
>     def __init__(self):
>         self.foo = Foo()
>
>     def bar_method(self):
>         return self.foo.bar()
>
> The former will allow me to use:
>
> x = Bar()
> x.foo.foo_method()
>
> But, with this I'm directly accessing methods of a member variable (strong
> coupling).
>
> The benefits I see with this approach are:
>
>    - I don't have to wrap every new method that gets added to class Foo.
>    - Bar may contain more member variables pointing to other classes. Not
>    wrapping them keeps Bar smaller and manageable in size.
>    - The auto-completion facility from IDE (PyCharm, etc.) or IPython helps
>    inspect bar like a menu (x.foo) followed by a sub-menu (
>    x.foo.foo_method(), x.bar.foobar(), etc.) making it easier to develop
>    code.
>    - Functional programming look-n-feel (not sure if this a pro or con)
>
> The cons are strong coupling, not encapsulating internal details of foo,
> etc.
>
> I wanted to check if this a recommended practice? And/or if there are any
> guidelines related to this (kind of implementing a composite pattern)?
>
> There may be more classes (Bat(), etc.) in future and I'd like to extend
> Foo in future to store an object of these classes. Foo() is a part of a
> library and my intent is to make Foo() as the entry point for the target
> users (to allow them auto-completion via dotted notation) rather than
> having them remember all the classes Bar(), Bat(), etc.
>
> Any inputs/pointers will be highly appreciated!
>
>
> Regards
>
> Sharad
>
>
> PS> I've posted this in SO at
> http://stackoverflow.com/questions/39231932/whats-the-
> correct-way-to-access-methods-of-a-member-variable-in-a-
> class-pointin/39237874#39237874
> but I'm looking for more information/ideas/thoughts/opinions on this.
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>


More information about the Tutor mailing list