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
Many times I hear "Singleton is a bad practice, static methods are bad practice" all I can see for reason is "hard to test".
But I do think sometimes its really good if an operation can be done without instantiate a class.
EDIT: just because of testing, anyone can find out that "private methods are bad too, they cant be tested" for example
It is a question about semantics and expressing intent.
A static method is not inherently bad, apart from that it is hard to test. The bad part is confusing other programmers by using static methods just to avoid creating new instances.
If the method relates to the class itself and not to individual instances (Like a factory method for example), then by all means use a static one. But if the method semantically belongs to an individual instance, then use a non static method.
Static methods are generally frowned upon for much the same reason as global variables, in addition to testing issues:
Static methods do not relate to a specific class instance so will not always be thread safe.
Systems with lots of statics methods often do not scale well.
Confusion due to the mixture between calling static methods of a class and members of an instance of a class can lead to maintenance issues.
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 3 years ago.
Improve this question
In unversity, my tutor told me always use private variables in class and have a setter and getter function, because it provides better encapsulation. But what is encapsulation? Is there any resons to do so if I know my code is only going to be developed by myself? It's just simpler to use my_obj.var instead of my_obj.set_var(var)!
Encapsulation in the classroom means making an over-engineered 2D point struct. Completely contrived and useless. It does a disservice to the entire concept by teaching it with poor examples.
Encapsulation in the real world is e.g. std::vector which works how you expect and is safe due to not allowing you to tamper with its internals.
In short: no, it's not necessary. It really depends on what you're doing.
In particular, you want encapsulation if your object is handling dynamically-allocated resources directly. So all properly-implemented container types should use encapsulation to prevent you from accidentally breaking it.
But if your type is just a pair of ints or some other raw data, there's really no need.
Specifically, getters and setters should be used if the details of the implementation could potentially change at some later point in the future. E.g. a struct representing a timespan could be represented as seconds:minutes:hours, but could also just be (a lot of) milliseconds. The getters and setters would allow you to turn that into seconds/minutes/etc. without it actually having to be stored that way internally. The operating word here is internal representation.
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 7 years ago.
Improve this question
I am working on a C++ project, where the lead is saying that private/public doesn't matter in practice, and so that all the classes should have only public members. Basically, he wants C++ with struct only.
His main argument is that huge code bases were written in C without private, and no bugs would have been prevented in those code bases by having a private keyword, so why bother?
I am countering by saying that private state is cleaner modularization, that it makes the code easier to reason about, easier to test, easier to refactor, that I could write assertions to make assumptions explicit with private state, that different teams could work independently by just agreeing on the interface of classes, but nothing seems to convince him.
What are the purely technical/objective arguments in this discussion, for/against struct/class with private members? It is a given that there is no generic answer, but I would like to list all the objective arguments I could use to evaluate which one to use in any given situation. Something like reasonable guidelines that we could all agree on, or an analysis grid that would tell us which one to use, given parameters of the situation. I would like to steer clear from personal preferences, as discussion of personal preferences is probably not productive.
It would be particularly useful to see a few concrete examples that demonstrate the pros/cons of each in specific situations.
My answer would be, "No, there is nothing to add." As you said, he has already dismissed good reasons. Maybe he's pleased with himself for recognizing that code can work without any private members, so he's being stubborn. I don't know.
A struct is fine where it makes sense, but people (like me) who have maintained code extensively know that encapsulation does improve design.
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'm making a calendar application in c++ and I'm making a great number of overloaded constructors for the appointment class depending on the information provided(e.g. if i have a start time for the event but no end time, and a location, but no attached contacts)
class Appointment {
public:
//overloaded Constructors
Appointment();
Appointment(Date);
Appointment(Date,Date);
Appointment(Date,Date,std::string);
Appointment(Date,Date,std::string,std::string);
Appointment(Date,Date,std::string,std::string,Contact);
etc. etc. Is there a better way to do this?
You could either:
Create the object (a valid one) and set its properties afterwards via interface setters (since it seems an object can have a variable number of properties this seems like a good choice)
Use default parameters, e.g.
Appointment(Date=getDefaultDate(),
Date=getDefaultDate(),
std::string=getDefaultString(),
std::string=getDefaultString(),
Contact=getDefaultContact());
It really boils down to how you prefer to handle and initialize your objects.
An important sidenote: in large production codebases default parameters is a C++ feature often frowned upon because it might hinder readability and/or render debugging more difficult in particular scenarios (especially when something unwanted goes on and you didn't consider a default parameter being chosen, default parameters are specified on the declaration and that might also "hides" a potential problem from the developers)
This is totally unnecessary. As pointed out Macro A , you can default construct the object and afterwards you can use setters for them.
One more thing when designing a software you should keep in mind the rule of complete and minimal i.e you should provide all facilities in a class avoiding duplication/redundancy.
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 hear a lot that RTTI can be avoided by using good virtual functions...since RTTI is clunky and slow, why should I use it? Are there any situations where I should use RTTI instead of virtual accessor functions?
RTTI can be used to solve the double dispatch problem (a function that behaves virtually based off the dynamic type of two objects).
RTTI gives you automatic access to the class inheritance graph of types with virtual methods.
Like some other language features, if you only want a restricted subset of its features (if you are ok with a centralized list, or single implementation inheritance, or even single binary, or lack of availability early/late in execution, etc) you can sometimes implement a more efficient, restricted version.
In addition, often double dispatch can be refactored into orthogonal single dispatches. And even if RTTI allows multiple dispatch, the code remains messy and difficult to maintain and RTTI can be a non trivial cost (note that compilers are much better at it now). So often a simpler, seemingly less efficient single dispatch solution ends up being a better idea anyhow.
RTTI can also be used in despirwtion when you need dynamic dispatch, but have no access to the ability to add new virtual methods for whatever reason.
Tightly coupled classes that expose pure interfaces but need to work with each others guts can use RTTI when paranoid about the dangers of blind static_cast as well.
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 8 years ago.
Improve this question
This is basically what i am now using a lot in my application for accessing objects that needed to be accessed from many classes:
Application::getInstance()->getComponentList()
Still think that this is not the good way how to access objects that need to be shared among many classes.
Question is if there is better approach to share objects in big application.
I have to agree with you and juanchopanza: accessing objects via a single singleton object throughout an entire project is a poor practice since modules are supposed to have few and well-stated dependencies among them (ideally: interfaces or means of communication).
Also: it's easy to violate the single responsibility principle.
There's no "do X instead of the singleton approach" solution, or no silver bullet: sometimes a singleton can really be useful but if possible: avoid it and design a clear interface instead.
Also: there isn't enough information in your question to state something more specific.