Tag Info

New answers tagged

3

When to use chaining Function chaining is mostly popular with languages where an IDE with auto-complete is common place. For example, almost all C# developers use Visual Studio. Therefore, if you're developing with C# adding chaining to your methods can be a time saver for users of that class because Visual Studio will assist you in building the chain. On ...


0

You could also do the method chaining thing with copy return rather than modify return. A good C# example is string.Replace(a,b) which doesn't change the string on which it was invoked but instead returns a new string allowing you to chain merrily away.


0

(I assumed C++ as your programming-language) For me this is mostly a readability aspect. If A, B, C are modifiers, especially if this is a temporary object passed as a parameter to some function, e.g. do_something( CPerson('name').age(24).height(160).weight(70) ); compared to { CPerson person('name'); person.set_age(24); ...


0

Those methods modify the own instance. Depending on the language, having methods that return void/unit and modify their instance or parameters is non-idiomatic. Even in languages that used to do that more (C#, C++), it is going out of fashion with the shift towards more functional style programming (immutable objects, pure functions). But let's assume ...


2

I think you can use the visitor pattern here. The class with the doStuff method should implement the Visitor interface. This interface has overloaded doStuff(..) (or visit) methods for all subtypes of the SuperClass. The SuperClass has an abstract method accept(Visitor) method and all subclasses implement this by visitor.doStuff(this), calling the correct ...


1

I would agree with Karl Bielefeldt's answer to move doStuff to the SuperClass with different implementations in SubA and SubB, or more specifically keep doStuff where you have it and only call methods on the passed in SuperClass object in the places where the the implementation differs for SubA and SubB: public void doStuff(SuperClass object){ // do ...


7

Basically, doStuff should belong to SuperClass instead of your other class, then SubClassA and SubClassB each have their own implementations. Sometimes you might be able to pull only a small part of doStuff into SuperClass. You might need to make OtherClass an argument of doStuff. It's hard to say more without more details. The bottom line is you need to ...


4

The problem here is that either doStuff or SuperClass (or both) is too general to accurately describe what should be done in this action (method). The only reason you would need to check the types here is that they are poorly designed to begin with and don't offer enough of a contract to take that action. Since you don't say what doStuff or SuperClass is ...


2

An aside: You have parameters default value set to null and then the first thing you do is null check them. Have you tried method overloading. Ie public static function MakeFromName(String mystring) { MakeFromName(mystring, GameBaseClass.INSTANCE.currentAtlas, GameBaseClass.INSTANCE.currentData) }


2

Yes, it's very bad practice, for several reasons, including at least: Global state is bad in general. By having code that only uses the global state when the argument is null, you allow it to be used correctly and to be tested, but any other code that uses your code with a null argument then becomes problematic, as it inherits this global state. If you ...


0

Couldn't you do something like that: class GameObject { public static function MakeFromName( pName:String, pAtlas:TextureAtlas = GameBaseClass.INSTANCE.currentAtlas, pGameData:Object = GameBaseClass.INSTANCE.currentData ):GameObject { var theSymbolData:Object = ...


0

I don't think your defaults create the coupling. I think you wanting them is a sign that the coupling already exists. There are at least two other signs of tight coupling here: You're not even using those parameters directly, you're using members of those parameters, which is a Law of Demeter violation. Wanting multiple factory-like methods that call ...


6

That is perfectly fine. This is often the compromise between the "passing everything in makes it too complex!" and the "using a static directly makes things inflexible and hard to test!" camps. Personally, I would only do this if the common (75%+) usage is to use the default instance. Otherwise, people will go with the easiest route (less arguments) which ...


3

If those parameters are not optional, then raise an exception. Is they shoudn't be optional, then Intelligent defaults are a good idea. Also if GameBaseClass is a top abstraction, you are adhering to the Dependency Inversion Principle. Your class depends on an abstraction not on a concretion.



Top 50 recent answers are included