Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

22
  • So, instead of an object with fields and perhaps methods, no objects, no records, just a whole lot of scalar values passed to and returned from static methods? Edit: Your new example suggests otherwise: Objects, just without instance methods? Otherwise, what's Thing? Commented Jun 3, 2014 at 21:28
  • What happens when you need to swap your FileLoader for one that reads from a socket? Or a mock for testing? Or one that opens a zip file? Commented Jun 3, 2014 at 21:28
  • similar, but less broad questions were asked and answered few times before: Can't I just use all static methods?, Make methods that do not depend on instance fields, static?, How to deal with static utility classes when designing for testability etc Commented Jun 3, 2014 at 21:29
  • 1
    @delnan Okay I figured out a question that the answer will help me understand: why would you implement a 'static' part of the system as an object? Like the example in the question: a save-file mechanism. What do I gain from implementing it in an object? Commented Jun 3, 2014 at 21:40
  • 1
    The default should be to use a non-static object. Only use static classes if you feel that it really expresses your intention better. System.Math in .NET is an example of something that makes a lot more sense as a static class: you're never going to need to swap it out or mock it and none of the operations could logically be made part of an instance. I really don't think your 'saving' example fits that bill. Commented Jun 4, 2014 at 6:42