Where should I put my first method
I need to add a method that will calculate the weighted amount of the worker's salary and his highest salary. I would like something like this:
class CompanyFinanse
{
public decimal WeightedSumOfWorkerSalaryAndSuperior(Worker WorkerA, Worker Superior)
{
return WorkerA.Salary + Superior.Salary * 2;
}
}
Is this a good design or should I put this method elsewhere? I am just looking at the design draft and thinking about a good object oriented way of organizing methods in classes. So I would like to start from the very beginning with OOP. Best practice is needed!
source to share
Thus, it may not be possible to give you a complete "best practice" answer without knowing more about your domain, but I can tell you that you can set yourself up for disaster by thinking about the implementation details first.
If you're like me, you've been taught that a good OOD / OOP is meticulously detailed and includes BDUF . It was only in my career that I learned that this is the reason why many projects become blatantly unattainable later in the future. It makes assumptions about how the project might work, rather than letting the design naturally flow out of how the code will actually be used.
Simply put: you need to do BDD / TDD (Behavior / Test Development).
- Start with a rough outline of the domain, but avoid too much detail.
- Select the functional area you want to start with. Preferably at the top of the model or one user will interact with.
- Brainstorm the expected functionality a block should have and make a list.
- Run a TDD loop on that device and then re-tune the repeater aggressively as you go.
What you get is exactly what you need and you won't do anything (in most cases). You get the added benefit of having complete testing coverage so you can refactor it later along the way without worrying about breaking things :)
I know I didn’t give you any code here, but that’s because everything I’m giving you is likely to be wrong and then you will get stuck on it. Only you know how the code will actually be used, and you should start by writing the code that way. TDD focuses on how the code should look like, and then you can fill in the implementation details as you go.
A complete explanation of this is beyond the scope of this post, but there are many resources available on the Internet, as well as a number of books that are excellent resources for getting started with TDD practice. These two guys need to get you good.
source to share
I would either put it in a working class or put a static function in the finance library. I don't think the Finance object really makes sense, I think it will be more a set of business rules than anything, so it will be static.
public class Worker {
public Worker Superior {get;set;}
public readonly decimal WeightedSalary {
get {
return (Superior.Salary * 2) + (this.Salary)
}
}
public decimal Salary {get;set;}
}
or
public static class Finance {
public static decimal WeightedSumOfWorkerSalaryAndSuperior(Worker WorkerA, Worker Superior) {
return WorkerA.Salary + Superior.Salary * 2; }
}
source to share
For your design to be object oriented, you must start by considering the purpose of the entire application. If your application only has one method (weighted sum) then there isn't too much design to go on.
If this is a funding app, perhaps you might have a salary class that contains the worker's salary and some useful functions.
Regarding the method you specified, if the Worker class has a reference to its Superior, you can make that method part of the Worker class.
Without more information on the purpose of the application, it is difficult to provide good guidance.
source to share
Following on from brien's answer, I suggest looking into the CRC card (Class-Responsibility-Collaboration) scheme . There are many sources of information, including:
- this tutorial from Cal Poly,
- this targeting on the Agile Modeling website and
- CRC Card book , which discusses practice and its use with multiple languages.
Understanding which class should "own" a particular behavior (and / or which classes should interact to implement a given use case) is generally a top-down discussion, driven by the overall design of what your system does for its users.
source to share
It's easy to find out if your code needs improvement. Your snippet has a code smell . You must turn to this.
It's good that you have a very declarative name for the method. But it takes too long. It looks like if you store this method in this class Finanse
, you will inevitably have to use all these words in the method name to understand what this method is intended to do.
This basically means that this method may not belong to this class.
One way to deal with this code smell is to see if you can get a shorter method name if we have a method in another class. I can see that you have classes Worker
and Salary
.
Assuming these are just leftover classes and you don't want to add more classes, I would put this on Salary
. Salary
knows how to calculate a weighted salary given a different salary (in this case, the senior salary). Now you don't need more than two words for a method name.
@ Shawn's answer is one option to eliminate this code smell. (I think you can call it "long method name code smell")
source to share