Should this be its own class?
-
I'm working on a Windows forms application that shows a list of PDFs in a given folder, with a toolbar with buttons that carry out operations on the list of PDFs. The form has a data grid view that takes as its data source a list (PDFlist) of objects (PDFentry) that have properties file name, file date, file size, etc. (Like Windows Explorer). Because the operations are carried out on the entire list of PDFs, the code for the various operations necessarily loops through PDFlist, acting on each item. That's a lot of code, so form.cs is pretty big (900+ lines). It seemed to me that PDFlist could be its own class, inheriting from List and adding methods for the various operations. Then form.cs would just have a line that said PDFlist.Compress(), or PDFlist.Print(), or whatever the operation was. But then the red flag was that there's only ever one instance of PDFlist. It's not a singleton in the sense that I don't have to prevent a second instance from being created. It's just that the application only uses one PDFlist throughout. Would this be a case where a static class is appropriate?
-
I'm working on a Windows forms application that shows a list of PDFs in a given folder, with a toolbar with buttons that carry out operations on the list of PDFs. The form has a data grid view that takes as its data source a list (PDFlist) of objects (PDFentry) that have properties file name, file date, file size, etc. (Like Windows Explorer). Because the operations are carried out on the entire list of PDFs, the code for the various operations necessarily loops through PDFlist, acting on each item. That's a lot of code, so form.cs is pretty big (900+ lines). It seemed to me that PDFlist could be its own class, inheriting from List and adding methods for the various operations. Then form.cs would just have a line that said PDFlist.Compress(), or PDFlist.Print(), or whatever the operation was. But then the red flag was that there's only ever one instance of PDFlist. It's not a singleton in the sense that I don't have to prevent a second instance from being created. It's just that the application only uses one PDFlist throughout. Would this be a case where a static class is appropriate?
One thing I have painfully learned is that while a static may work now, at some point you will end up using it from multiple threads and then all hell will break loose. If the class has any state, try not to make is global or thread static. Also, these types of errors are some of the worse to debug.
"Time flies like an arrow. Fruit flies like a banana."
-
I'm working on a Windows forms application that shows a list of PDFs in a given folder, with a toolbar with buttons that carry out operations on the list of PDFs. The form has a data grid view that takes as its data source a list (PDFlist) of objects (PDFentry) that have properties file name, file date, file size, etc. (Like Windows Explorer). Because the operations are carried out on the entire list of PDFs, the code for the various operations necessarily loops through PDFlist, acting on each item. That's a lot of code, so form.cs is pretty big (900+ lines). It seemed to me that PDFlist could be its own class, inheriting from List and adding methods for the various operations. Then form.cs would just have a line that said PDFlist.Compress(), or PDFlist.Print(), or whatever the operation was. But then the red flag was that there's only ever one instance of PDFlist. It's not a singleton in the sense that I don't have to prevent a second instance from being created. It's just that the application only uses one PDFlist throughout. Would this be a case where a static class is appropriate?
-
I'm working on a Windows forms application that shows a list of PDFs in a given folder, with a toolbar with buttons that carry out operations on the list of PDFs. The form has a data grid view that takes as its data source a list (PDFlist) of objects (PDFentry) that have properties file name, file date, file size, etc. (Like Windows Explorer). Because the operations are carried out on the entire list of PDFs, the code for the various operations necessarily loops through PDFlist, acting on each item. That's a lot of code, so form.cs is pretty big (900+ lines). It seemed to me that PDFlist could be its own class, inheriting from List and adding methods for the various operations. Then form.cs would just have a line that said PDFlist.Compress(), or PDFlist.Print(), or whatever the operation was. But then the red flag was that there's only ever one instance of PDFlist. It's not a singleton in the sense that I don't have to prevent a second instance from being created. It's just that the application only uses one PDFlist throughout. Would this be a case where a static class is appropriate?
I have (static) "adapter" classes; similar in concept to a "table adapter" and its "fill" (a table) method, etc. Static, because often there is no instance data other than the object being operated on. Just makes calls simpler when you don't need a instance reference to an adapter. Adapters, for me, often make more sense than adding methods to an object, which then operate on "itself".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I have (static) "adapter" classes; similar in concept to a "table adapter" and its "fill" (a table) method, etc. Static, because often there is no instance data other than the object being operated on. Just makes calls simpler when you don't need a instance reference to an adapter. Adapters, for me, often make more sense than adding methods to an object, which then operate on "itself".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
You can be a successful marketer when you follow given tips like Establish Organization Goal, marketing Strategy, Time Alerts, Filter Method, Audience Requirement and more. RetrievInfo providing all information about business marketing. It is a treasure of knowledge.
Visit on: https://retrievinfo.com