I have made a lot of forms for my desktop application, some forms were using the same method which I have to copy and paste the code (not OOP).

Let's say I have a method called FirstDayOfWeek() and this method is needed in 5 forms, that means I need to copy and paste the code 4 times to the other forms.

What I want to ask is:

  1. If I want to put this FirstDayOfWeek() in a new class, should I make it as default or static (Instance or Static)? So if there's an update for this method I don't need to tweak it in 5 forms.
  2. Which has better performance; Instance, Static or just Procedural code (copy and paste)?
  • 1
    What does the method return? The first day of the current week (so a DateTime) or a weekday (DayOfWeek.Sunday, DayOfWeek.Monday)? Does it depend on user preferences and/or locale? – Glorfindel Jan 21 '19 at 8:33
  • 1
    the method returning datetime. Does it depend on user preferences and/or locale? what does it mean ? its more customize method. i just worry about heap-stack memory. and worry about the performance – chopperfield Jan 21 '19 at 8:41

The answer to your question is simple, but without additional context it can lead to overapplication of the same pattern in more complex scenarios where it is no longer correct to do so.

The short answer

Statics are the way to go in this case. The main reason being that this is a helper method whose result is not bound by a given context.

The long answer

The correct method depends on the goal of the method and how it achieves this.

Static methods should be used in cases where the method's purpose is not contextual and globally applicable. The logic required to find the first day of the week is always the same.

However, suppose your users are able to choose which day is the first day of the week (Sat/Sun/Mon). Now your logic to find the first day of the week is contextual and no longer globally correct (it depends on the user). While this can still be done using statics by passing the user (or their chosen day); this becomes more cumbersome when you consider more complicated example.
The better option here is to use dependency injection to inject behavior. Create multiple classes, each being an implementation of the same base class. This is a very complex topic that I can't explain from scratch, but I hope the key difference (contextuality) is clear.


There is no meaningful difference between static and instanced methods. The cost of instantiating an object is massively negligible. The only thing that can impact performance is if you have expensive logic in your constructor, but that would imply that you need this expensive logic in the constructor and thus cannot work without it, so it's still not really an issue that you should work to avoid (any more than you otherwise would).

As an aside:

Procedural code (copy and paste)

That's not procedural code. Procedural code suggests that it is generated by some tool (pun not intended), not copy/pasted by a developer.

Copy/pasted code is never the right approach, unless you can prove that these multiple instances are functionally independent of each other. In other words: they can become very different things, and the fact that they currently do the same thing is coincidence; there is no requirement that when you update one you must update all the others.
Spoiler alert: 9 times out of 10 when developers think multiple instances of the same method is the right approach, it's not.

| improve this answer | |
  • 4
    Procedural code, rather procedural programming, is a style of programming centered around procedures, or subroutines, not tool generated code. Otherwise +1. – Greg Burghardt Jan 21 '19 at 15:51

You shouldn't worry too much about performance here. This method isn't going to be called hundreds of times per second. You do worry about reusability, which is great (and not limited to OOP, by the way).

If you just need a simple method which returns the first day of the current week, create a static method in a Utility class:

public static class Utility {
    public static DateTime FirstDayOfCurrentWeek() {
        // your code goes here

This way, it's the simplest to call from your forms (or anywhere else in the application).

If you get many more of these methods, create separate utility classes like DateUtility, StringUtility, etc.

| improve this answer | |
  • so you are suggesting that if i have another method, i need to create new static class ? 1 static class for 1 static method ? – chopperfield Jan 21 '19 at 8:51
  • 2
    In theory, if they aren't logically related, they should be in separate classes. But if you have five Utility-type methods, I wouldn't worry about separate classes; if you have a hundred, I would. – Glorfindel Jan 21 '19 at 8:53
  • @chopperfield: That's a contextual decision. Usually, you see these separated based on general functionality (DateHelper, StringHelper, ...) as the global nature of statics tends to imply that the static methods are globally applicable to a given type, thus separating on said type. – Flater Jan 21 '19 at 11:22
  • Downvote because of the use of "utility" class where it's clearly not needed. This is a common domain problem, where a "Calendar" object may be exactly the place to put a method like this. Naming is hard, and pointing the correct naming to things makes a whole difference on your development practices, specially if you use Domain Driven Design. EDIT: I'll gladly upvote this if y ou change from a generic "Utility" class to a "Calendar" one. – Machado Jan 21 '19 at 16:43

If the code for FirstDayOfWeek is something like:

DayOfWeek FirstDayOfWeek() => DayOfWeek.Monday;

ie, the value returned is hard-coded, then make it a static method.

If the code instead determines which day is the first day of the week based on the user's configuration or locale, then it should be an instance method and should be exposed to those forms via an interface and dependency injection.

| improve this answer | |
  • for my case is- first day of week were sunday, and i need to make it monday, because the value for day were different (for calculation) hence i need to make it static method – chopperfield Jan 22 '19 at 4:59

Naming is hard. If you properly name your objects and what they're doing, things get a little bit clear.

So, let's assume you're trying to create some sort of Calendar object or extended DateTime API.

What you are describing may fall into 3 distinct categories:

  1. A Factory Method which would be static, and may always return the same object given you have no parameters.
  2. A simple Property, which may be read-only depending upon your domain model and your object, which would NOT be static.
  3. A constant which could be visible outside your class or not, depending upon your architecture.

All 3 of them are correct, depending on the context.

So, without more information about what does "First Day of Week" mean, with the proper naming of your object and a little bit more information about the problem you're trying to solve, there's no possible way to give you a fair advice.

Naming is hard.

Side note: Dates and Times are also hard. You can understand that by a quick peak on the number of articles on TheDailyWTF about it. I'd strongly suggest you take a look into NodaTime if you need anything advanced prior developing your own date/time manipulating functions.

Side note 2: First Day of Week is a malleable concept, which involves calendar days (check here as well) and business days.

| improve this answer | |
  • 1
    thanks for your insight. for my case is where as the parameter is Datetime.Now which will return the date of first week. e.g. parameter (26Jan19) will return 21Jan19, i need to make it custom where data from database and computer for the first week is different. from data were monday as computer were sunday – chopperfield Jan 22 '19 at 4:57
  • That's good. It seems you need something to work the same way as the CultureInfo object does. I suggest you edit your first post and add the example you showed, so that'll help other people understand it better and give other answers as well. StackOverflow has a few examples, like this and this. – Machado Jan 22 '19 at 11:57
  • Also, if you notice, the examples on SO that I've linked uses a 4th option, which is to create Extension Methods to the DateTime struct. Given you're working with .Net I think it's a perfectly valid solution to reduce the noise and boilerplate code for simple stuff. A CustomDateTimeExtensions class with your specific methods is a valid approach. – Machado Jan 22 '19 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.