On Thu, Jun 16, 2016 at 11:40 AM, Alan Gauld via Tutor <tutor@python.org> wrote: > On 16/06/16 16:38, boB Stepp wrote: > >> class FTPFiles(FTP, object): >> """FTP files to Windows server location(s).""" > > OK, First comment. You describe this as an action(verb) > rather than a noun. Classes should represent nouns > (objects) not actions. FTP represents a protocol > connection with which you can do things (one of > which is put/get files) you class should be the same. > (Remember inheritance m,eans you are imp0lementing > an "is a" relationship. So FTPFiles is an FTP...or > should be.)
I was struggling to come up with a good name here that would not cause me any name collision issues with the contents of ftplib.FTP(). I have for the moment changed the class name to "CustomFTP", which bothers me for some reason that I cannot put my finger on. However, this looks to become a non-issue; see below. >> 4) As this class stuff is mostly treading new ground for me, am I >> doing anything that I should not be doing or should do in a more >> preferred way? Keep in mind that I am just starting on this code >> today. > > I'll leave someone with more ftplib experience to answer the other > points but the question I'd ask is what are you planning to add to FTP? > Creating a new class by inheritance implies that you are going to be > extending (or specializing) its capabilities in some way. What are you > planning to extend/specialize? For example are you going to limit it to > manipulating files only? ie prevent listing directories say? My first objective was just to play around with inheritance as a learning opportunity. Now that I have gotten it to work and have somewhat a feel for the possibilities, I am actually going to abandon it for this specific project. I think I can use the FTP class unmodified and just write appropriate helper functions to get the specifics of what I want, passing my specific FTP instance object to these functions. > You need to know what you are changing to warrant using inheritance. > Inheritance is a powerful tool but it carries lots of potential for > problems too, especially if you plan on mixing your new class in with > the old one (or sharing it with others who will) - you need to be > careful to abide by the Liskov substitution principle (LSP). I looked up LSP last night. I can see how I can easily get burned even on something seemingly simple. One example, which I imagine is often used, is of a square class inheriting from a rectangle class. Squares have same sized sides; rectangles not necessarily so. So any size changing methods from the rectangle class inherited by the square class can potentially wreak havoc on squares. Am I getting the essence of the potential issues I might encounter? boB _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
