Inheritance versus Composition

Re:Inheritance versus Composition by jnwatson on Thursday May 09, 2019 @01:56AM (#19865751)

Python is build entirely around the idea that encapsulation is mostly useless. "We're all consenting adults" is the general philosophy. As long as there's a convention as to what properties are "public" and which are not, a motivated user of a class should be able to do what they want with it.

There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary.

This vastly simplified the design of OO in Python, and it makes testing far far easier. There's no need to go through the dependency injection acrobatics in order to change one method for testing or proxying.

(There technically is a way to munge a property name in Python but its use is discouraged).

[ Parent | on HN ]

Re:Inheritance versus Composition by mschuetz on Thursday May 09, 2019 @04:19AM (#19866335)

I wish there was a "do not touch unless you know what you're doing" field. Private fields and members are a nuisance if you need to do some unsupported thing with a library. On the other hand, there are often utility functions in an object that are absolutely only ever meant to be used by that object itself, and not to be called from the outside.

[ Parent | on HN ]

Re:Inheritance versus Composition by zeveb on Friday May 10, 2019 @05:48AM (#19876384)

Python supports those by prefacing with "__", IIRC.

[ Parent | on HN ]

Re:Inheritance versus Composition by scarface74 on Thursday May 09, 2019 @08:51AM (#19867799)

There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary.

It’s about intention. If I mark a property or method as private, it means that I can get rid of it, rename it or change the expected behavior without considering it a breaking chance.

[ Parent | on HN ]

Re:Inheritance versus Composition by marcosdumay on Thursday May 09, 2019 @01:10PM (#19870082)

Yeah, and Python has some standard nomenclature for marking a property as protected and a little bit of behavior for helping mark it as private. You do not need encapsulation for that.

[ Parent | on HN ]

Re:Inheritance versus Composition by scarface74 on Thursday May 09, 2019 @01:33PM (#19870278)

And there is nothing about the Pythom runtime stopping someone from using it anyway.

With a statically typed language, you really have to go out of your way to do it like using reflection and if your code breaks on an update you get what you deserve.

[ Parent | on HN ]

Re:Inheritance versus Composition by kevin_thibedeau on Thursday May 09, 2019 @11:31AM (#19869154)

YAGNI rules the day.

[ Parent | on HN ]

Re:Inheritance versus Composition by scarface74 on Thursday May 09, 2019 @12:49PM (#19869865)

You’ve never had to refactor code that was used as a library by other developers?

Do you realize how many hacks is built into Windows just because developers were using undocumented features?

[ Parent | on HN ]

Re:Inheritance versus Composition by arunix on Thursday May 09, 2019 @07:30AM (#19867186)

> (There technically is a way to munge a property name in Python but its use is discouraged).

Do you have a reference for that (i.e. the discouraged part)?

[ Parent | on HN ]