Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What is the ideal number of properties and methods in a class? What considerations must be made in determining this?
There is no "ideal number of properties and methods" but there are the SOLID principles to which you should adhere if you want to have a good OO design.
But if you try to implement the Universe following the God Object anti-pattern the number is close to infinity.
The answer is, 42. It can be arbitrarily split between properties and methods.
Make some "private" because it's more intriguing when objects have something to hide.
This shouldn't be a question of numbers. A class should encapsulate a logical unit of code. You'll get a number of funny answers (one just popped in as I'm writing this ;) because it's kind of beside the point. If you have a concrete case however, you might want to put it into your question; there could be cases where a strange task may end up giving you a class with too many methods; that would probably be a sign of a design problem somewhere else.
There are really no ideal numbers. If a class is supposed to have hundreds of methods, and they logical behave to its domain, then use those methods.
Since good oop practices tends to maximize code reuse, then it's quite probable that a class can't reach a very large number of methods or properties without encounting the need to be splitted.
If you follow SOLID principles you are most likely to end up with the most appropriate number. The number of members of a type will differ a lot depending on the purpose of this type. There is no magic number available that will fit all the cases.
As few as possible, but no less, unless strictly necessary.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
If I have many classes which are pretty similar with each other then, does making them inherit from an abstract class a good option?
Only if they are a true abstraction in the Dog is an Animal kind of sense. Stuff on your abstract classes must make sense to all derived.
Otherwise you risk using your base class to sort of import an API. Although you see some frameworks do this, without deliberate design you are usually better off extracting the commonality out to shared dependencies which all the classes commonly use.
Abstract classes that no client code directly references or uses is typically a sign you may be running off track.
Absolutely. Though I would use an interface/protocol where possible. They're more flexible, as they give you the freedom to inherit another class.
The best choice depends on the nature of your classes, and what their duplicated code is.
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 6 years ago.
Improve this question
I'm almost new to programming and I came to this question that:
why should object carry code along with data? isn't packing data enough?
For example:
Instead of having 5 employee objects that each has a getDataOfBirth() method (consuming more memory), have a single method in global space and have 5 object with only attributes(smaller objects).
Am I getting something wrong? Is my question even considered general and possible to be occurred in every newbie's mind?
The linguistic aspect of it:
This is an idea that OOP skeptics have been talking about for a long time, but it's more of a matter of preference I would say. If you are new to programming and already are thinking about these things, then maybe functional programming would make a lot of sense to you.
The memory aspect of it:
The functions are typically not stored inside the objects, so OO objects that have a lot of functions do typically not carry those functions around. This is however an implementation detail but most OOP languages should be thought of like that.
Especially in the case of natively compiled languages like C++, the code and the data will be separated into different memory areas altogether and will not really mix. That is also a bit of an implementation detail but all mainstream operating systems, as far as I know, will allocate memory with code separated from data. The functions of a class will be allocated in one area and the data of the objects in another, and normally all objects of the same class will use the same functions.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm currently developing a school project and we are instructed that we are required to implement Object-Oriented Programming concepts in our software. But I don't want to implement it just by simply inheriting this class to that class and overriding this method to implement its own functionality and so on. Though it is still acceptable but I want to do it differently. By differently, I mean by using design patterns. I'm trying to understand it one by one and I noticed that some of them are very useful(Builder, Memento and Adapter). But the problem is there are so many of them and if possible I want to put/implement it all(those 3 design pattern). Is it okay if I do that? Would it mess up the project as a whole?
As always: It depends.
Overusage of patterns on small and simple bits of code can obscure the code. But it can also make it more clear.
Don't use patterns wherever possible. Use them when it serves a purpose. Every pattern has its purpose and if you can't find that purpose in your code, you shouldn't rewrite it to match a pattern. Try to keep your code a) maintainable and b) easy to read. If a pattern fulfills these criteria more than your approach without patterns: go for it.
You can have code with dozens of patterns and code with none. In both cases it can be the ideal choice.
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 9 years ago.
Improve this question
I was asked in an interview what structure I would use to store 100 names: an NSDictionary or NSArray and why.
What is the best answer?
He said he wants to figure out whether a name exists.
This is an open ended question, and the interviewer is probably more interested in your thought process and the questions you ask. The short answer IMO is NSArray if you just need to enumerate objects. NSDictionary if you need to lookup objects by a key. And NSSet when you just need to check membership. Of course this all varies depending on the amount of items, and how they are being used. With 100 items, it is probably 6 one, 1/2 dozen the other. And more a matter of readability and understandability in the code.
Read this old, but not outdated article for an excellent look at the performance considerations of each collection. http://www.cocoawithlove.com/2008/08/nsarray-or-nsset-nsdictionary-or.html
I think this has some good explanations of the two even though it's more focused on the performance aspect https://stackoverflow.com/a/10545362/1415348
It's really ends up being more open ended b/c it depends on what you might want to do with the data.
And now that it's edited with more info about how they want to use it I'd agree with Hot Licks, NSSet would be best for that. It has the method containsObject to determine existence in the set. NSSet Class Reference
The best answer is to ask more questions to clarify the requirements.
What kind of names?
What languages and locales?
How will they be used?
Will they change or be static?
Is there a storage or performance concern?
And so on.
In all likelihood the goal was to find out how you think about design.
Even if they didn't answer further questions they probably expected at least some reasoning provided for using various data structures where you illustrate how they can be used and why they make sense.
I seriously doubt they expected a one word response
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 always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.