Reputation
6,913
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
3 22 30
Newest
 Yearling
Impact
~201k people reached

May
22
comment C# obtain derived class from base
+1 for the overload approach, but your WidgetToJavaScriptConverter instance could be called from a simple loop without the added indirection of a visitor pattern.
May
22
comment C# obtain derived class from base
You could construct a parallel hierarchy of javascript generating classes and then use a dictionary or other "linking" mechanism to first register and later select the correct javascript generating class for each widget class. ("Is there a way to loop through all the widgets, but determine what type of widget it is?" - TypeOf() method?)
May
19
comment Advantage/Disadvantage of having all variables declared in a JUnit Test
+1 for the case you make. And test code should be production grade code. That said, DRY is not so much about not repeating yourself at all. It is about not repeating knowledge. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” (en.wikipedia.org/wiki/Don%27t_repeat_yourself). The misunderstandings arise from "repeat" I think, as does: hermanradtke.com/2013/02/06/misunderstanding-dry.html
May
19
comment Advantage/Disadvantage of having all variables declared in a JUnit Test
+1 absolutely, but please bear in mind that DRY is less about avoiding repeating code than it is about not repeating knowledge. See hermanradtke.com/2013/02/06/misunderstanding-dry.html. The Dry principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." en.wikipedia.org/wiki/Don%27t_repeat_yourself
May
19
comment Advantage/Disadvantage of having all variables declared in a JUnit Test
@CandiedOrange: DRY is less to do with avoiding code duplication than it is about avoiding the duplication of knowledge (facts, rules, etc). See: hermanradtke.com/2013/02/06/misunderstanding-dry.html The Dry principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." en.wikipedia.org/wiki/Don%27t_repeat_yourself
May
9
comment Do I need to use an interface when only one class will ever implement it?
Found a perfect use case for an interface implemented by a single class just now, in this thread: programmers.stackexchange.com/questions/281979/…
May
9
comment Is my usage of explicit casting operator reasonable or a bad hack?
You could avoid the copying by using an ISmallObject interface implemented by BigObject and simply return a reference to this in the ToSmallObject implementation.
May
9
comment Is my usage of explicit casting operator reasonable or a bad hack?
This sounds like a perfect use case for an ISmallObject interface which is only implemented by BigObject as a means to provide access to a limited set of its extensive data/behavior. Especially when combined with @Telastyn's idea of a ToSmallObject method.
May
9
comment Do I need to use an interface when only one class will ever implement it?
How about the only class implementing that interface does more than just implement that particular interface and you don't want the code needing only the methods of said interface to have access to the rest of the public methods of the class. For eaxmple classes that implement both "immutable" and "mutable" behavior and you want most of your code to have an extra "insulation" layer between them and the methods that change an instance's state (insulation provided by having to "ask" whether the "mutable" interface is supported) so it is easy to spot the code that messes with state.
May
4
comment Web API Design advice
"which seems to be going against RESTful approach or dealing with resources?" you are confusing resources with entities. A resource can consist of many attributes and sub objects containing lists as well. The same way that a view is not restricted to any particular entity. You can structure your resources any way you see fit given the needs of your application. Considering that you plan to use this thing in many places, I would certainly opt for a single resource that pulls everything together for me.
Apr
27
comment Two way communication between Form and plugins
No time to go into any detail now, so comment instead of answer. They way you make every Panel (or UserControl as suggested by CurtisHx) able to receive information from the main form, and/or to add menu items to the main form is to turn it onto its head: make all panels/UserControls implement an interface that allows the mainform to ask each one for any menu items it wants to add and allows the mainform to "broadcast" information from other panels to anyone interested. The latter is the published-subscriber pattern: every panel automatically becomes a subscriber of the mainform.
Apr
8
comment Should one use Dependency Injection even if the class is used only once?
dependency injection need not be centralized at all (see other answers). And even though this class may be used only once, it still needs to be tested for its behavior. Plus, more importantly, the class using it needs to be tested. And though you could test both classes through the outer one (the one aggregating the other class), your test classes and cases will be much simpler if you focus them on a single class. Which means that the outer class needs to be tested only for its own behavior and its interaction with the inner class. And that automatically is an argument for some form of DI.
Apr
8
comment Unit testing and reusing extracted class
DO test this class to check that it actually uses the classes it is aggregating/composing and to ensure that it keeps doing that. Injecting your creator classes is going to make that a lot easier. I'd even go as far as to see that without a mocking framework that can fake on the fly, you have no option but to use injection. So your option 3.
Apr
8
comment Abstract Web API from validation and configuration management in embedded system
You seem to be on a nice track, but could you please enlighten me wrt the meaning of TAD? Google is bringing up stuff that doesn't make much sense in the context of your question.
Apr
6
comment Unit test strategy for layered (or derived) method calls
Almost two years on, I am in a more lenient mood :) Here's a discussion with a code example: Testing strategy for validation and action methods. C# example, but shouldn't be too difficult to adapt to language of choice.
Mar
28
comment TDD - Outside In vs Inside Out
Interesting. How did you reach the conclusion that outside in TDD is "mockist" TDD? I very much prefer Outside-In thinking and design and thus testing (see softwareonastring.com/2015/01/10/…) yet the Fowler article firmly puts me with Fowler in the classicist camp. While mockist may always use an outside-in approach, you can't turn it around and say that outside-in design and testing is mockist TDD. Outside-in can be and very much is practised by classicist TDD-ers as well.
Mar
16
comment Should we test all our methods?
Why would you check that your DAL has only been called once?
Feb
20
comment Cheap implementations in fundamental TDD
@alfe and to answer your question of how strict you should apply something: dogma is never the answer to anything. Keep using your brain. When you start to rely on strict dogmatic application of anything, everybody loses.
Feb
20
comment Cheap implementations in fundamental TDD
@alfe What then: you add more test cases. TDD doesn't require you to be complete from the start. In fact it specifically allows for requirements and implementations to change over time and to be refactored / added to with changes in perception of what the behavior should be. Test cases that test for behavior that is later found to be redundant can and should be removed. Test cases are a living breathing code base, just like the production code. Think of them as the dynamic documentation of your requirements (which change over time) and as a history of bugs solved.
Feb
20
comment Cheap implementations in fundamental TDD
@alfe instead of expanding an existing test case, you can always add an extra one. Each test should cover just one aspect of a function/method. Doesn't mean there can only be one assert (it often takes more than one assert to verify an aspect); but your second scenario should probably have its own test method within the testclass instead of being added to the first.