Reputation
644
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
3 10
Newest
 Yearling
Impact
~24k people reached

Nov
12
comment The granularity level to repeat code: should downloading, unzipping etc. be handled by separate classes?
@PiotrFalkowski Agree about the interface (I expressed doubts about DI). My answer is about extracting and granularity.
Nov
12
comment The granularity level to repeat code: should downloading, unzipping etc. be handled by separate classes?
@whatsisname I agree with your conclusion that it's only three lines. But I could see it as good reuse if they're repeated (DRY) and/or dilute the cohesion of the classes where they're placed. C# is not my strength, but If you wanted to start counting bytes transferred, attempt re-try on connection failures, or throttle download requests, wouldn't this be a good encapsulation?
Nov
12
comment Are first person comments distracting and unprofessional?
How about first-person refactoring: OurFormIsNotResized = (WindowState <> 1) ... If OurFormIsNotResized Then ...
Nov
12
comment The granularity level to repeat code: should downloading, unzipping etc. be handled by separate classes?
@whatsisname Can you say (without using sarcasm) why it's not significant? If the code appeared a three different places (say in three other classes) wouldn't it be useful to make a pure fabrication?
Nov
12
answered The granularity level to repeat code: should downloading, unzipping etc. be handled by separate classes?
Nov
11
comment Are there any significant disadvantages to depending upon abstractions?
@SteveCallender I found reading a lot of Robert Martin's texts made my brain hurt, but at the same time it's intriguing to see the metrics, namely the graph you mentioned on page 13. Abstractness or concreteness of packages is far from intuitive. I wouldn't worry about it, as I don't think it's wise to do top-down designs of packages using these metrics. Even if you measure arbitrary packages, it's not clear how you would refactor them. I found the package design strategies from Craig Larman's Applying UML and Patterns to be more straightforward.
Nov
11
comment Are there any significant disadvantages to depending upon abstractions?
@Spotted No problem about not being able to patch. It's just a pretty specific example and not typical of most software.
Nov
11
comment Are there any significant disadvantages to depending upon abstractions?
@Eilon my comment was about modularity is not always needed (not abstractions).
Nov
11
revised Are there any significant disadvantages to depending upon abstractions?
added 32 characters in body
Nov
11
answered Are there any significant disadvantages to depending upon abstractions?
Nov
11
comment Are there any significant disadvantages to depending upon abstractions?
I tend to agree with YAGNI, but I wonder about your example. Are you never repeating any code in the different devices? I find it hard to believe that there isn't some common code across the devices from the same company. Also, how do clients like when you don't fix bugs in their firmware? Are you saying there never are bugs, ever? If you have the same code that's buggy in 4 different implementations, you have to fix the bug 4 times if it's not in a common module.
Nov
9
answered Design pattern for fetching data in chunks
Oct
4
comment Single responsibility policy problem
each module should have only one reason to change -- this is in terms of software evolution (changes in source code, not changes in state).
Oct
4
comment Single responsibility policy problem
I'm not sure that single-responsibility applies here. It's got nothing to do with memory overhead or redundant state.
Sep
18
comment Reducing the complexity of a class
Explain to the folks upstairs the difference between essential complexity and accidental complexity. en.wikipedia.org/wiki/No_Silver_Bullet If you're sure that complexity that is breaking the rule is essential, then if you refactor per programmers.stackexchange.com/a/297414/51948 you're possibly skating around the rule and spreading out the complexity. If encapsulating things into phases isn't arbitrary (the phases relate to the problem) and the redesign reduces the cognitive load for developers maintaining the code, then it makes sense to do this.
Sep
18
comment MVC controller and decoupling explained
It's OK for View to know the Model. The GoF design is based on the assumption that Views are less stable than the Models over the time of a project. If you make a change in your Vews, you don't want the Model code to be affected. The best example of this is Microsoft Word. The user interface (Views) of a document have changed a lot over the years, but the file format (the underlying model of what is a document) has changed much less.
Aug
21
comment Strategy pattern and “Is a” relationship
I added with an edit some ways you can manage strategies around a context. StrategyManager is not really a class in the pattern, but it's the class that has the responsibility to instantiate and configure concrete strategies. The goal of the pattern is to decouple the context from the strategies. Adding new strategies would require modifying StrategyManager but not Context.
Aug
21
revised Strategy pattern and “Is a” relationship
Added dynamics
Aug
21
comment Strategy pattern and “Is a” relationship
You can make a factory to create the strategies if you want to encapsulate that logic from context. I think that strategy always has the same method call. You want that method call to be polymorphic otherwise it's not the strategy pattern. It's hard to answer the question about injection because your code does not show much detail.
Aug
21
answered Strategy pattern and “Is a” relationship