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 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I keep seeing code where class variables are declared after methods at the bottom like
class Observer
{
public:
int getstate();
void update(int state);
private:
int state;
};
Is this a common practice I should adapt to? Is there a reason for ordering them like this?
It is a commonly used way to structure the code but it is not mandated by the language. You are free to format your code as you wish. The most important thing to remember is:
Code is written for people, not for machines.
Keep that in mind and put yourself in the shoes of the next person who will be reading your code. It should be crystal clear.
Is this a common practice I should adapt to? Is there a reason for ordering them like this?
You don't have to. Either order works. The choice is subjective. I don't think there's a significant reason to prefer one order over the other myself.
However, I do recommend ordering public members - whether variables or functions - before protected and those before private. This is because public interface of the class is more likely to be important to a programmer who reads the class definition. Ordering the important parts first potentially reduces the time that the reader has to spend to find what they're looking for.
I also recommend getting used to a variety of different orders, as each programmer has their own preferences and there won't be consitency between different projects, nor even necessarily within a project.
Most people choose to put public first because developers and editors generally need the more important information. It also makes the code easier and clearer.
Related
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 new to OOP and I'm trying to create a program. Basically it's a store and it has products and clients and all that stuff. However, I'm struggling with a question.
When it comes to OOP, does it make sense to create a class to represent the stock of the products? Something like:
class Stock
{
private:
Product *_product;
int _nrOfProducts;
...
};
I'm asking because initially I had thought about it being an atribute of the product but then I started wondering things like "What if I delete a product? All of its information will be lost - including the stock, which I still need".
Thanks in advance!
A lot of tutorials will tell you otherwise, but in general objects are better at modeling abstractions in your software that capture behavior rather than modelling objects in the physical world. That's just data, whereas an object or better yet an interface is about capturing and abstracting behavior that can vary depending upon the situation.
As to the decision to cache the number of products v.s. not. The typical answer is, "It depends." Frequently you won't need to, because you'll be using a more sophisticated collection type that gives you an easy "count" operation. You might need that stored separately for some other reason though.
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
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.
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 9 years ago.
Improve this question
I have a project that contains several classes. I added to this project several functions that are used by one of the classes, let named MainClass. I put all these functions in a file stuff.h. To use these functions I include the stuff.h file at the beginning of the implementation of the class MainClass. I am wondering if this is a good style of programming or if it would be better to create a new class and add my functions to this class. Then I instantiate this class in the MainClass.
Not so good style. Starting from the fact headers are not actually intended to have real code but declarations of things defined somewhere else.
If your 'external' functions are used only by MainClass why not to do them class methods? Even maybe private so they are only visible inside class? Keep things as encapsulated as you can. If you're trying to follow C++, try not to use 'plain C functions'. It's different language. If you absolutely need plain routines, use namespaces instead. But please try to keep your code inside modules (.cpp), not in headers.
Regarding other classes. It depends if you know why you need other classes. If you don't know why, you don't need them. BTW OOP is not always 'best' approach, especially in things like balance between inheritance and composition. You should understand what you really want to achieve to select proper technique.
Indeed you need good C++ book. Chapters about project composition, compilation process, translation units so you will understand logics behind this. This Q&A site cannot explain you everything. Just give some points.
Good question here for you
I think it would be better to create a new class, or several new classes that are ordered by the different ways the functions will be used. That's more in line with classic OO.