28
votes
Are "need to call objects in parent object" and "avoid circular dependency" reasons to avoid "Tell, don't ask"?
Ultimately, you're pushing all the program logic into class Manager. Everything else is only a dumb interface. As the program develops, Manager gets bigger and bigger, until it's an unmaintainable ...
7
votes
Are "need to call objects in parent object" and "avoid circular dependency" reasons to avoid "Tell, don't ask"?
The point is to reduce how much Manager knows. Also, SystemMoniter should only know its things. it shouldn't need to know about Leds, Speakers, or the Screen. And actually, neither should the Manager.
...
4
votes
Are "need to call objects in parent object" and "avoid circular dependency" reasons to avoid "Tell, don't ask"?
The problem I see here is a good old fashioned coupling problem.
Your 'bad' does too much. Then in 'good' you delegate to something else that also does too much. This is not progress.
public class ...
2
votes
For non-container classes, are "better naming" and "ready for commented codes" good reasons not to declare the most abstract type?
Type strategy has nothing to do with what kind of class you're dealing with, it applies to Containers in the same way as to non-containers. If all you do is drive(), then you should deal with a Car ...
1
vote
For non-container classes, are "better naming" and "ready for commented codes" good reasons not to declare the most abstract type?
Your problems boil down to two things:
The "most abstract type" depends on what you do with the object
Variable names should tell you what the reader needs to know, not what the compiler ...
1
vote
Is it necessary or "class obsession" (opposite to primitive obsession) to create classes for non-business fields?
If you want to put the dialog showing logic in another class then do it like you mean it.
public class MyActivity extends Activity{
onResume(){
welcome.considerShowingDialog();
}
}
...
Only top scored, non community-wiki answers of a minimum length are eligible
Related Tags
coding-style × 1042coding-standards × 147
java × 101
c++ × 98
code-quality × 92
programming-practices × 75
python × 74
c# × 73
clean-code × 69
design × 53
c × 51
object-oriented × 45
javascript × 45
naming × 44
readability × 37
php × 27
design-patterns × 26
language-agnostic × 24
comments × 22
conditions × 19
refactoring × 18
code-reviews × 18
architecture × 17
exceptions × 16
functions × 16