Reputation
662
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
3 11
Newest
 Cleanup
Impact
~25k people reached

Feb
9
comment Help in understanding computer science, programming and abstraction
@MichaelT it works with PlantUML locally (-metadata option), but I don't think they have a cloud service yet (github.com/plantuml/plantuml-server/issues/21). I'll put my PlantUML diagrams on imgur from now on since I can get back the source. Thanks for the draw.io example.
Feb
9
comment Help in understanding computer science, programming and abstraction
@MichaelT I like that example. I think PlantUML has a recover feature. I'll see if I can get it to work.
Feb
9
comment Help in understanding computer science, programming and abstraction
@MichaelT Not sure how to comment on this, but I rolled back the edit because the Image is important to stress "real world objects" (LRG) and putting the UML image on IMGUR will lose its source code (the plantuml URL has a key that is a hash of the code to edit the image, as well as the SVG format of the diagram contains text that can be indexed by web crawlers).
Feb
6
comment “Selected design can be derived from requirements” - meaning and difference against traceability?
Normally standards define terms like correctness and derive. Does 12207 do that?
Jan
19
comment Why should a builder be an inner class instead of in its own class file?
I think the real test to see if a Builder implementation holds up to the GoF definition is to make a new variant of a concrete builder. If the concrete builder (or its abstract hierarchy) is somehow nested as an inner class, I can't see how the design can be extended.
Jan
19
comment Why should a builder be an inner class instead of in its own class file?
I think the Builder pattern has morphed a bit since being documented in 1995. @Joppe has a point -- the GoF definition of Builder says "Use the builder pattern when * the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled." The example is an RTFtext converter, where the built products are ASCIIText, TeXText, etc. The pattern with an inner class is not consistent with the GoF class diagram (I'm adding it to your answer for clarity).
Jan
19
comment Advantages of having multiple apps or sub apps SPAs in AngularJS SPA
I'm not an expert in AngularJS, so I won't speak of performance advantages if they exist. But the advantage to breaking down modules as you suggest is that if you want to extend your app(s), the modules are theoretically more reusable than if you put everything into one big app. For example, the app.login could be useful in any app that requires authentication (assuming it's the same authentication scheme). The same could be true for payment, catalog, etc.
Dec
29
comment Are exceptions as control flow considered a serious antipattern? If so, Why?
Wikipedia's definition of anti-pattern says it's common. Given you never saw this again, and I've never seen it ever, maybe it's just bad style and not technically an anti-pattern?
Dec
22
comment Is it true that for Observer Pattern to work, there probably is some polling mechanism underneath?
Polling means software is actively sampling the status of something. If your macbook's CPU was spending time "constantly asking," it would be too slow to do any work.
Nov
16
comment Advantages of Strategy Pattern
Can you be clearer about why it's easier to test? The example for refactoring a case statement (or if/then) to a polymorphic method (basis for strategy) is pretty easy to test. refactoring.com/catalog/replaceConditionalWithPolymorphism.html If I know all the conditions to test for, I write a test for each. If I have strategies, I have to instantiate and execute one for each. How is the strategy approach easier to test? We're not talking about complex nested ifs when you refactor to strategy.
Nov
16
comment Advantages of Strategy Pattern
Is this homework? It's better to state that up-front if so.
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
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
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.
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).