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 1 year ago.
Improve this question
I have always struggled remembering key words in Object Oriented Programming, I feel like they are all used interchangeably, so can someone please take the time to explain the The difference between function, class, method, object and constructor? It does not really differ from language to language so any explanation will help but I'm learning Java and Dart right now. Thank you!
A "class" is a category of like things (think of the biological classification, or the set theory term (the thing that is bigger than a set), or just the word "classification.") If you need a more prosaic way to remember it, all the seats in first class are the same size and shape as each other, as are all the seats in economy class.
Objects are instances of some class. There can be many objects of a given class. Every object is unique from every other object; objects have identity. (Seats in economy class have seat numbers.)
Constructors make (construct!) objects. A class has constructors, with which you make objects of that class. The role of a constructor is to create an object with its representational invariants established (that is, create objects in a valid state.)
Functions/methods are behaviors, usually associated with a class.
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 1 year ago.
Improve this question
While searching on the internet for information I found it difficult to get a good understanding of which approach should be taken.
One concern is that Util or Helper class is considered an antipattern because it often violates Single Responsibility Principle.
Yet Util or Helper classes are still widely used.
Are there any good reasons to prefer one or another?
This question is probably too opinion-based…
But in my experience, most of the utility/helper methods I used to write in Java were related to a particular class or interface: I had a load of String- and char-based methods, a load of methods that used a Collection or List or array, a load of methods for handling Components and Frames and other Swing classes, and so on. I wasn't thinking of them as extension methods when I wrote them (mostly long ago!), but in hindsight that's how they seemed to go.
So when converting things to Kotlin, almost all of my utility methods fell out as top-level extension methods. I didn't initially intend that, but it seemed the most natural way.
And I expect that will apply to the majority of helper and utility methods. I'm sure there are cases where a utility class is more appropriate — but in my experience those cases are pretty rare.
You should also consider methods in companion objects; that's the most natural place for factory methods, and for other ‘static’ functionality that's closely related to a class without fitting into a normal instance method.
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 1 year ago.
Improve this question
I'm looking for a practical answer here, I understand Rust approach to OOP, composition over inheritance, writing traits to reuse code and all that jazz.... which is all fine if I had full control of the code and I could have chosen to write everything accordingly, but I'm stuck with the following scenario:
I'm trying to use cursive's TableView, which implements the View trait, and therefore its method on_event. I want to handle more events that those that come with the TableView implementation, but I want everything else, including the events that TableView already handles, to remain the same.
Since I've done OOP for the best part of 25 years, the natural thing for me to do is to extend TableView, implement on_event and call super.on_event where I see fit. This is not possible in Rust, as far as I understand.
I could have my own MyTable struct, which contains a TableView struct, implement the View trait on MyTable, and for every method just call the same method in TableView. I reject this as the proper solution, it can't be...
What's the closest I can get to OOPs super paradigm, or alternative, what is the Rust way of doing this without having to write a lot of useless code that just proxies calls to an inner struct of the type that I'm trying to extend?
Edit: For more detail on exactly what I want to accomplish please check this other question.
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 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.
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 4 years ago.
Improve this question
I have a web application (in ASP.NET MVC) with a Quotations controller. This controller can handle multiple Quotation types, MotorQuotation, PropertyQuotation, etc...
Currently it is using inheritance i.e. a Quotation model and it's children, to model the domain. The various children classes have differences in the data they store and not their behaviors. The difference in behavior would come with their validation methods as the validations can be different dependent on what unique fields a child class may store.
The question is how would someone model the quotation objects using composition instead of inheritance?
The way you describe the problem, it sounds like this is a good case for using inheritance. The rule of thumb is to use inheritance if A is-a B and to use composition if A is-implemented-in-terms-of B.
The recommendation to prefer composition to inheritance does not mean "never ever use inheritance". It means use inheritance appropriately. For example, if you write a Stack class in C++ using an std::vector, you don't want to derive Stack from vector. A Stack is not a vector, it is implemented-in-terms-of a vector, which implies composition. You also want to avoid creating deep class hierarchies, because that results in tight coupling.
In your case, however, inheritance seems like an obvious choice.