#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2013
    Posts
    100
    Rep Power
    2

    Classes in Python: Do we really need it?


    I've just started reading about classes and here's what I think:
    Do we really need them? Ya, I mean, to read others' code; but when writing our own code, we can always create nested defs inside of a single def to put things together. Why are classes essential, I cannot get the point.
    P.S. It's kind of a sophisticated concept, you know, you have to manage instances, the __init__, __str__,__add__ methods (I know that they are not compulsory to add to your code but whenever added).
    Last edited by Akshat1; May 29th, 2013 at 02:25 PM.
  2. #2
  3. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2012
    Location
    Iran
    Posts
    149
    Rep Power
    139
    It's a matter of abstraction level for complex problems. Maybe the following gives you an idea:

    http://wiki.answers.com/Q/Benefits_of_object_oriented_programming

    And not forget the important fact that everything in python is an object
    Regards,
    Dariyoosh
  4. #3
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2012
    Location
    Tewksbury, MA
    Posts
    36
    Rep Power
    2
    Need??? No. Of course we don't really need closets, file cabinets, toolboxes or anything else that keeps the objects in our daily life handy either. But try doing without them...
  6. #4
  7. Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2005
    Posts
    610
    Rep Power
    65
    A class can inherit other classes, saves a lot of coding time.
    Real Programmers always confuse Christmas and Halloween because Oct31 == Dec25
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2012
    Posts
    194
    Rep Power
    2
    I don't quite understand the phobia that many new programmers seem to exhibit towards using classes. Classes make life EASIER; not the other way around. Also if you use literally any library/api everything will be using classes. Running from them really is just silly.

    -Mek
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Location
    Usually Japan when not on contract
    Posts
    240
    Rep Power
    12
    No, we don't need classes, but not at all for the reasons you are citing. They are more than a syntactic convenience when it comes to a certain set of jobs they are really the right tool for.

    For the vast majority of real code overhead is lower and processes are more readable and maintainable if you use Python's built-in data structures and write functions in a way that avoids state maintenance entirely. That is great for doing anything that needs to process an input and output a result -- which is actually most stuff you'll do.

    But then there is this whole thing where users need to interact with an ongoing program. Every time this is the case you are writing a simulation of an abstract machine or device -- and simulation is where classes are invaluable, because they permit you to think of your code like cogs in a machine, instead of it being a series of (possibly indeterminately branching) self-configuring pipelines.

    Use of classes magnifies global state to untestable levels very quickly (global state silently grows to levels that are untestable on today's hardware for the projected life of the universe), but reduces the conceptual complexity of interface design so much that the tradeoff is overwhelmingly worth it.

    That said, when you're not doing a simulation or other task where one thingy needs to be able to pass a message to another thingy (like you "push" a tooknab which in turn "switches on" a doohicky and then resets itself) then classes are not just overkill, they are a nail in the coffin of a project's long-term maintainability.

    And don't get me started on the wicker-castle problem that multiple-inheritance brings on, usually for no actual reason other than whoever started the project initially was blindly taught that OOP is the end-all at a school that was at some point infected with Java...
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2013
    Posts
    100
    Rep Power
    2
    Thanks everyone for replying. Really, thanks a lot; now I understand the importance of classes.
    Thanks again.
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Location
    Usually Japan when not on contract
    Posts
    240
    Rep Power
    12
    Just keep in mind that most people begin a program with "class Foo():" out of blind faith and a lack of mental hygiene, not because they actually need classes to solve their problems. If you are not solving an interface or simulation type problem you are almost always better off writing code based on functions instead of methods, and very often even when using classes better off making methods wrappers to externally defined function calls.

    Making everything a class makes refactoring core components impossible over the long run. Making interface elements (whether actual widgets or text-input handlers that are imaginary widgets in your mind) and logically interacting components in a simulation is a big win.

    Someone mentioned above that "well, in Python everything is an object". And that is true, in the broader sense of objects -- but it is often stated (as it was above) in a way that insinuates that everything you write should also be an object because Guido wrote language elements that way. This is wrong.

    The point of that design choice for the language is that Guido was designing a textual interface to the language. He designed the language itself as a set of interfaces with an object semantics of its own -- and on the back end the canonical implementation, CPython, is written in C, where there are functions and data structures, and no classy objects at all (which sort of blows the cover off the whole idea that "everything is an object"). The design of Python solves a different problem than you solve with your Python programs.

    So when you are designing your programs consider first whether you are actually trying to map an input to an output (the very definition of a function), or whether you are trying to build a simulation of an abstract world. The case is nearly always the mostly the former with a small smattering of the latter where complex interactive input is required.

IMN logo majestic logo threadwatch logo seochat tools logo