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 8 years ago.
Improve this question
I know that one method should be responsible for one action (or so I've been told) but let's it can't be avoided (or workaround is impractical). Imagine that a game of snake is being developed and it has to have two methods: one which simply moves snake forward and one which increments the length of the snake by one and moves it. First method could just be named move(), but how about the second one? Simpliest solution is to use and, but is it a good practice? For example: incrementAndMove(). What are the alternatives?
I would choose the name GrowAndMove, but semantically it is the same as what you propose. Still implement this method to call two separate methods - Grow and Move to keep each method responsible for a single aspect of the changes happening during a single step.
Related
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 5 years ago.
Improve this question
Feels like a question that has been asked before but I'm not exactly sure how to properly word it in a google search. Say I have a MainWindow object and in that object I define several objects PanelA, PanelB, PanelC and PanelD. What's a good way of connecting these objects to each other without having constructors that look like this
PanelA(PanelB* b, PanelC* c, PanelD* d)
Would you suggest to just pass them all in through the main class like so
PanelA(MainWindow* mw)
{
b=mw->b; c=mw->c; d=mw->d;
}
Or is there better ways to structure my classes. What's this problem known as in general, so that I can google this stuff myself.
What's this problem known as in general, so that I can google this stuff myself.
The design defect is known as strong coupling of types and use of hardcoded relations.
The general approach to refactor such code is to introduce interfaces and design patterns to solve the actual dependencies by means of functionality.
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
when I am going through the lambda function, I have seen people comparing lambda with functors & I came across a statement
users don't have to clutter their code with small functors in some accessible scope.
My doubt is
what is the problem in having small functors in some accessible scope
isn't it good idea to have a single function (functor actually) & reuse it across multiple files in our project.
Thanks.
it is unnecessary if you have to use each only once. Lambdas usually makes the code more readable, the function is defined exactly at the place it is needed.
this is not always the case, a function may be called at only one place. Of course if you needed it at different places a functor may be more appropriate.
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 6 years ago.
Improve this question
A simple example of how you would structure this would be particularly useful.
This is how I would do it:
MyMotor is an instance of the class Motor. This class has four functions idle(), accelerate(), flat(), decelerate(). (I assume you know how to build a basic class with private members and its constructors)
Then in main(), I create MyMotor and control it based on states. States can be controlled/monitored using Boolean Values. Whatever state I am in and whenever, certain function will be called.
Next time give it a try before you ask here, in order to get better responses.
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 8 years ago.
Improve this question
Should a thread-safe mechanism be added when a class is developed and it is known that this class will be used in multi-threaded environment (not always however) or leave it to the user?
As a general rule, it's more flexible to leave it to the user. For example, consider a map-type container. Suppose the application needs to atomically move something from one map to another map. In this case, the user needs to lock both maps before the insert-erase sequence.
Having such a scenario be automatically taken care of somehow by your class would probably be inelegant, because it's naturally something that happens across objects, and because there may be many such scenarios, each slightly different.
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 8 years ago.
Improve this question
Suppose that we have class C and our process is as follows
do func1
do func2
do func3
do func4
where each function operates on the data from the previous stage
Which is better from the point of view of system design?
make each func takes an input, returns its results and pass the result to the next stage
make each func operate on data members in the class c and they all return void
And if these 2 strategies are famous design patters what is the name of each design pattern?
If you use option 2, and you'll pass the code to another developer. If he/she accidentally calls func3(), func4() in the middle of the code, it will be logically wrong.
If you use option 1, the developer needs to think of the parameters which will be passed through. It is less likely that he will make mistake.
Therefore, I'll go with option 1.