Re: Newbie OO module-structure question

If you're thinking in terms of breaking it into tasks with a main module that has the core code, then you've probably already taken a wrong turn at OO. Tasks are verbs. Object-oriented code is structured around nouns.

So rather than having a module for archiving old files, you might have a class for representing files, and one of the methods it provided might be archive.

toby döt ink

Comment on Re: Newbie OO module-structure question Download Code

Replies are listed 'Best First'.
Re^2: Newbie OO module-structure question by Anonymous Monk on May 01, 2019 at 11:56 UTC
OP here. This, and BillKSmith's comment below, certainly makes sense, but in both cases, I'm not sure what the right approach would then be. That is, it seems to me that it's not unreasonable to have core code (as above, e.g. config, database connections, logging, etc.) in one central place, and other things in other places. But if I'm treating OO things as nouns, refactoring this code along these lines won't solve my (perceived) problem, which is that the code is really large. That is, if this program does deal with files (not exactly the case, but it works for this purpose), having a class representing files, and then methods for `archive`, `delete`, `convert`, etc., will still leave me a five-thousand line class with five methods in it, instead of a five-thousand line program with five sections. Am I worrying too much about the size of the monolithic block? Would five methods of this sort (which will, of course, have a number of accessory or utility sub-methods) be cleaner? It seems to me that it wouldn't, but....	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Newbie OO module-structure question
by Anonymous Monk on May 01, 2019 at 11:56 UTC

OP here. This, and BillKSmith's comment below, certainly makes sense, but in both cases, I'm not sure what the right approach would then be. That is, it seems to me that it's not unreasonable to have core code (as above, e.g. config, database connections, logging, etc.) in one central place, and other things in other places. But if I'm treating OO things as nouns, refactoring this code along these lines won't solve my (perceived) problem, which is that the code is really large.

That is, if this program does deal with files (not exactly the case, but it works for this purpose), having a class representing files, and then methods for archive, delete, convert, etc., will still leave me a five-thousand line class with five methods in it, instead of a five-thousand line program with five sections.

Am I worrying too much about the size of the monolithic block? Would five methods of this sort (which will, of course, have a number of accessory or utility sub-methods) be cleaner? It seems to me that it wouldn't, but....

[reply]
[d/l]
[select]