Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm used to using encapsulation no matter what, all of my variables are private.
But when I'm handling thousands of instances with thousands of properties, I start thinking about optimization, wondering if the benefits of encapsulation justify the performance penalty (if any)
I'm aware of why one should use encapsulation but what I'm asking about is: Is encapsulation worth the processing it requires if it's not required to be used ? How much does it use ?
I think you're missing the point of encapsulation. The point of encapsulation is that the object controls ALL interaction with it's fields. Thus enforcing business logic uniformly and protecting the state of the system. Given that you would have to run the business logic anyway... you're not saving anything by just using data objects.
Your first choice should be to encapsulate things. Most of the time, the setter and getter functions should get inlined.
All you "lose" is the time it takes for any extra logic involved in the actual verification that you are not setting an invalid value, etc. But you don't want to miss that out just for the sake of speed, would you?
So, if the alternative is to write
if (x >= 0) obj.x = x;
or
obj.setx(x); // where setx checks that x >= 0.
which is better?
If there are performance criteria for the system, then benchmark. If you are meeting the criteria, fine. If not, figure out where the bottlenecks are. But unless your setter and getter functions are "normal" ones (that is, just storing the value after some checking), it shouldn't be the bottlenecks. Typical bottlenecks are "poor choice of algorithms".
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I guess this question is for a large part a matter of what you prefer aswell as being very situational, but I just came across a path to a gameobject today with a pretty long reference, and I thought if a temp reference wouldn't be better for this situation.
The code:
if (enlargeableButtons[i][j].gameObject.activeSelf && enlargeableButtons[i][j].IsHighlighted())
{
enlargeableButtons[i][j].gameObject.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
In a case where the path is this long with multiple array indexes to check, it would definitely be faster, but because of the extra object also be more expensive to do it like this:
GameObject temp = enlargeableButtons[i][j].gameObject;
if (temp.activeSelf && temp.IsHighlighted())
{
temp.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
But how much and would it be worth it?
I seriously doubt you will see any performance gain using a direct reference instead of going through the jagged array.
Maybe if this code is running in a very tight loop with lots and lots of iterations, you might get a few milliseconds of difference.
However, from the readability point of view, the second option is much more readable - so I would definitely go with it.
As a rule - You should design your code for clarity, not for performance.
Write code that conveys the algorithm it is implementing in the clearest way possible.
Set performance goals and measure your code's performance against them.
If your code doesn't measure to your performance goals, Find the bottle necks and treat them.
Don't go wasting your time on nano-optimizations when you design the code.
and a personal story to illustrate what I mean:
I once wrote a project where I had a lot of obj.child.grandchild calls. after starting to write the project I've realized it's going to be so many calls I just created a property on the class I was working on referring to that grandchild and my code suddenly became much nicer.
Declaring GameObject temp just creates a reference to enlargeableButtons[i][j].gameObject. It is extra overhead, but not much. You won't notice a difference unless you're repeating that thousands of times or more.
As a personal rule, if I just need to reference it once, I don't bother with declaring a variable for it. But if I need to use something like enlargeableButtons[i][j].gameObject multiple times, then I declare a variable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I had an argument with my teammate about the following.
We need to parse a symbol in a string to int(it is always a digit), this particular functionality is used in a number of places. So this can be done this way:
var a = int.Parse(str[i].ToString());
The argument was: do we need to create a function for this.
int ToInt(char c) {
return int.Parse(c.ToString());
}
that can be used:
var a = ToInt(str[i]);
My opinion is that creating such a function is bad: it gives no benefits except for typing couple characters less (no, as we have autocomplete), but such practice increase a codebase and makes code more complecated to read by introducing additional functions. My teammate's reason is that this is more convinient to call just one such function and there is nothing bad in such a practice.
Actually question relates to a general: when it is ok(if at all) to wrapp combination of 2-3-4 functions with a new function?
So I would like to hear your opinions on that.
I argee that this is mostly defined based on personal preferences. But also I would like to hear some objective factors to define a convention for such situations in our project.
There are many reasons to create a new sub-routine/method/function. Here is a list of just a few.
When the subroutine is called more than once.
If it makes your code easier to read/understand.
Personal preference.
Actually, the design can be done in many ways of course, and depends on the actual design of the whole software, readability, easy of refactoring, and encapsulation. These things are to be considered on each occasion by its own.
But on this specific case, I think its better to keep it without a function and use it as the first example for many reasons:
Its actually one line of code.
The overhead of calling a function in performance will be far more the benefit you get from making it.
The compiler itself probably will unwrap it again into the one line call if you make it a function, though its not always the case.
The benefit you get from doing so, will be mainly if you want to add error checking, TryParse, etc... in the function.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I would like to know what is more optimal, A number N of private integer variables, or a single array containing N integer values.
When you use an array, that is a plus indirection. The array will be allocated at a separate part of the memory, so when you first access it, your code first obtains its address, then it is able to read out its content. It also needs some indexing, but that is done extremly fast by the CPU. However, .NET is a safe environment and it will do a check whether you use a valid array index. It adds additional time.
When you use separate variables, these will be encompassed by your object instance and no indirection is needed. Also, no index bound check is needed.
Moreover, you cannot name nicely the Nth element of an array, but you can give good names for individual variables. So your code will be readable.
As others mentioned, you shouldn't do this kind of optimalizations, the compiler/jitter take care of it. The compiler knows several common use cases and has optimialization strategy for that. If you start doing tricky things, the compiler will not recognize your intention and cannot make the optimalization for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Here's an example. I saw a "ReadOnlyDictionary" class online and it had the following code:
void ICollection.CopyTo(Array array, int index)
{
ICollection collection = new List<KeyValuePair<TKey, TValue>>(this._source);
collection.CopyTo(array, index);
}
For example, should I check array for a null argument, or should I let the the CopyTo method do that for me? It just seems a bit redundent, but if best practices say to check everything in your own method, then that's what I want to do. I'm just not sure what "best practices" says to do.
I think it wise to say if you plan to do something with array that relies on it NOT being null then you should check this. But if it just a pass through then I don't see a reason why you should check.
Another thought is if the method gets complicated in the future. You might still want to check for it because someone may modify the code and use array without realizing that it might be null. This is only for maintaining good code in my opinion.
If somebody else's library or API* is going to complain about my inputs, I don't want to give it those inputs, I want to validate and/or complain first. This is especially important if calls into external APIs are expensive, such as a database or web service call.
You know what inputs the API is going to reject. Don't send those, invalidate them in your own public API.
*Note: I consider my own public boundaries to be the same thing. If I have class Foo that does not like given arguments, if I invoke Foo, at some level before doing so, I'm going to validate my arguments. You don't do this at every level (assume there are layers of indirection, maybe, private methods calling into private methods, etc.), but at some reasonable public boundary, I will validate. Validate early, don't let complicated logic or work be done when it's just going to be rejected anyway.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Is it best practice to place method bodies before or after they are called ? I generally place them after; interested in what others are doing ?
I prefer after. The reason for this is because it makes the flow of your code more logical. Code flows from top to bottom anyway, so it's logical that methods called appear after the current method.
This has the added advantage of the entry point of your program/class being at the top, which is where you start looking anyway.
When developing Java, I place the method bodies after they are called. This will typically result in classes that have a small number of public methods at the top, followed by quite a few private methods at the bottom. I think this makes the class easier to read and understand: you just need to read those few public methods at the top to understand what the class does — in many cases you can stop reading once you get to the private methods.
I also note that Java IDEs typically place the method body after the current method when you refactor code. For example in Eclipse, if you select a block of code and click Refactor | Extract Method... it will place that selected code in a new method below the current one.
It is entirely a matter of personal preference. For most people, the code navigation facilities of a modern IDE mean that it hardly makes any difference how the methods are ordered.
The method placement is largely irrelevant to me (of course in case of some static methods that need to be defined before invoked):
The code formatters are usually in place (and running automatically - if not for you, turn them on) which results in the source being ordered nicely by type of the method and then alphabetically, rather without the regard to the method call sequence
I use the modern IDE, where finding the proper method is done in a different way than sequentially going through the whole source