I've just finished refactoring an awful C# class. I had been delaying the job for a while because I didn't want to do it.
Then, while staring at the code, I realised I could simply delete all the private methods and fields, leaving the public interface intact, and then re-implement the class in a much cleaner way. Great idea! I finished the job in a few hours, with a brand new class that doesn't give me a headache.
This is the first time I've actually seen a real value in having private and public scope for methods and variables. It makes refactoring much safer and easier! So... why don't we have them in Python?
Subscribe to:
Post Comments (Atom)
Popular Posts
-
These are the robots I've been working on for the last 12 months. They each weigh about 11 tonnes and have a 17 meter reach. The control... -
This hard-to-see screenshot is a Generic Node Graph Editing framework I'm building. I'm hoping it can be used for any kind of node... -
So, you've created a car prefab using WheelCollider components, and now you can apply a motorTorque to make the whole thing move along. ... -
MiddleMan: A Pub/Sub and Request/Response server in Go. This is my first Go project. It is a rewrite of an existing Python server, based o...
-
Often, when building a game, you need to test if objects are colliding. The objects could be spaceships, rocks, mouse pointers, laser beams....
-
I've just read a newspaper article (courtesy of Kranzky ) from WA Business News documenting the malfeasance, gross negligence and misc...
-
After my last post, I decided to benchmark the scaling properties of Stackless, Kamaelia, Fibra using the same hackysack algorithm. Left axi... -
Possibly slightly more correct lighting. The rim light is now only applied in the direction of the sun, rather than being purely based on vi... -
Update: This is another planet shader, with more physical fidelity. Shader "Planet" { Properties { _MainTex ("Diff... -
At the last few GameJams, I've seen an increase in the use of RAD game tools, some of them even being developed by the participants them...
17 comments:
We do.
It's just that if you *need* to, you can access the private classes too. If you do that with your own library, then you probably need to refactor it. If you do it with somebody elses, you have to count on it breaking when he refactors the code.
The lack of an actual "private" keyword doesn't stop you from separating your code into a public API and internal implementation.
Just use the standard Python convention that attributes / methods starting with an underscore are private.
In addition to the under and dunder, you can use things like properties to refactor a seemingly public variable to act like a method.
I agree that the model is helpful.
I know it's helpful. So is static typing, it's extremely helpful when refactoring legacy code. But that's not what python is about which simplicity and minimalism.
If you want to be able to refactor python code easily you need to make sure you have good unit tests.
Please see the tutorial at http://docs.python.org/tutorial/classes.html#tut-private for more information about this.
>>> class A:
... def __private(self):
... return 2
... def public(self):
... return self.__private()
...
>>> a = A()
>>> a.__private()
Traceback (most recent call last):
File "", line 1, in
AttributeError: A instance has no attribute '__private'
>>> a.public()
2
Right, I had forgotten about the underscore prefix system. I guess it fell from memory due to lack of use, because it is so ugly!
Then you should have forgotten all of your C# because it's so ugly.
Actually, it's so much more readable and explicite than a keyword in the declaration.
I must agree with Simon, underscore prefix is ugly. I can't understand why there isn't "real" private scope, it feels so fundamental when thinking about encapsulation.
Though I don't have much experience with procedural languages.
if you have private and public then you should add protected and internal and there are still situations when all the 4 options are not good enough. It just adds a lot of complexity in order to get more control. Learn give up control you control freaks!
First: Python is not only procedural...
Second: Python has a philosophie, and it defined the language. Thats the main reason to avoid the use of keywords like private, static, etc.
Good points. I'm thinking this completely from the Java point of view so I missed this Python philosophy.
__slots__ ?
But until today, nobody convinced me why make attributes and methods really private
This isn't about keywords on implementations, this is about interfaces, right? Most Python software doesn't need explicit public interfaces. And those that do use zope.interface. I don't mean to be so blunt, but after years of using one of the following two strategies, it seems a non-problem; either: (1) duck-type and use data-normalization decorators around your public methods (e.g. guarantee your REST API can give your method that needs strings a unicode value without issue; move the EAFB and normalization into a decorator for more elegant, readable methods); (2) use zope.interface and zope.component. You can use both.
s/EAFB/EAFP
You can separate interface and implementation using closures. To me this seems much less natural in Python compared to JavaScript where it's the norm. I would like a better syntax for this.
def make_class():
global X
def private_method(self): pass
class X(object):
def public_method(self):
private_method(self)
Post a Comment