Comments on: 97TESPK: Scoping Methods http://jexp.de/blog/2010/03/scoping-methods/ Sat, 14 Apr 2012 08:35:18 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jens Nerche http://jexp.de/blog/2010/03/scoping-methods/comment-page-1/#comment-143 Jens Nerche Wed, 10 Mar 2010 14:21:59 +0000 http://jexp.de/wp/?p=26#comment-143 Hi Michael, it seems your discussion misses some details. Let me play devils advocate and to formulate some protest notes: Scoping Methods lead to anemic domain models. Because one logical class is spread over some physical classes, each containing some methods, there is no hidden information with public operations on it anymore just like in service-dto-dao-architectures. The former private methods, which operate on the class data, now need dto's for input and output, no real internal hidden state anymore. Not only the data isn't protected anymore, there is also no private method anymore. Things may become visible to far more objects than they should, and it unsafer to change things. In the same namespace are now far more classes than before, which leads to fat namespaces (packages). And because the lack of any naming convention its not obvious which code belongs together. Before scoping the cohesive code was in one class, now its spread over all the namespace. The code is now much less readable, now you have to switch between files instead of having it on one screen or scroll some pages up and down. There is also much more syntactic sugar to write and read. "Transit dependencies" are common: that are dependencies that are injected in the original class - not for the own use, but only to pass them to the newly created method objects (which in turn may pass them only to <i> their </i> method objects and so on...) There is no real point for having method <i> objects </i> - static utility methods could also do the job. They could be imported statically and are in the original class as readable as private methods. And its a heaven for utility methods collection classes. We could also define abstraction levels 1-10 and have a utility method class per abstraction level just as we could have a database table per data type and spread the entity over them ;-> Well, not really.... Perhaps the object oriented paradigm is the wrong one for the abstraction hierarchies you are seeking for. In the described form Scoping Methods is more one of the "97 Bad Ideas Every Programmer Should Know". Don't get me wrong, I'm not trying to bash you or so, I'm just playing the devil to point out some antitheses. live long and prosper jens Hi Michael,
it seems your discussion misses some details. Let me play devils advocate and to formulate some protest notes:

Scoping Methods lead to anemic domain models. Because one logical class is spread over some physical classes, each containing some methods, there is no hidden information with public operations on it anymore just like in service-dto-dao-architectures. The former private methods, which operate on the class data, now need dto’s for input and output, no real internal hidden state anymore.

Not only the data isn’t protected anymore, there is also no private method anymore. Things may become visible to far more objects than they should, and it unsafer to change things.

In the same namespace are now far more classes than before, which leads to fat namespaces (packages). And because the lack of any naming convention its not obvious which code belongs together. Before scoping the cohesive code was in one class, now its spread over all the namespace.

The code is now much less readable, now you have to switch between files instead of having it on one screen or scroll some pages up and down. There is also much more syntactic sugar to write and read.

“Transit dependencies” are common: that are dependencies that are injected in the original class – not for the own use, but only to pass them to the newly created method objects (which in turn may pass them only to their method objects and so on…)

There is no real point for having method objects – static utility methods could also do the job. They could be imported statically and are in the original class as readable as private methods. And its a heaven for utility methods collection classes. We could also define abstraction levels 1-10 and have a utility method class per abstraction level just as we could have a database table per data type and spread the entity over them ;-> Well, not really….

Perhaps the object oriented paradigm is the wrong one for the abstraction hierarchies you are seeking for. In the described form Scoping Methods is more one of the “97 Bad Ideas Every Programmer Should Know”.

Don’t get me wrong, I’m not trying to bash you or so, I’m just playing the devil to point out some antitheses.

live long and prosper
jens

]]>