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 4 years ago.
Improve this question
I'm searching for a concrete definition of operation and method independent of the programming language.
In my understanding:
Operations just specify which functionality an object supports without
any implementation. It seems to be like a prototype in a C header.
Methods specify the concrete implementations an object supports. It seems to be like an implemented C function.
Question:
Why do we speak of abstract methods? In my opinion abstract methods should be the same like operations.
Searching pascal.computer.org for operation gives numerous and varied definitions. In the context of this question, the second seems most fitting.
in programming, a defined action that can be performed by a computer system
That definition sounds vague in isolation, but ties nicely into the definition of method.
implementation of an operation
...which is exactly as stated in the question. However, I think these formal definitions differ from colloquial usage. The term operation is somewhat rare in OOP. I would use it in the context of a mathematical operation, especially as the action of a mathematical operator, but not as a substitute for a method definition. Abstract method would be a more common phrase in that case.
Likewise, while method is a quintessential OOP term, it is not typically used to call out an implementation. Concrete method would be the inverse of abstract method. I think the lesson is that while academic definitions exist, programmers don't necessarily speak that way. This is no different to common conversation diverging from the dictionary.
See also: What's the difference between a method and a function?
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 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 5 years ago.
Improve this question
I've read numerous articles (1,2) about the pitfalls of inheritance and the other options that you can consider.
I've never understood deep inheritance hierarchy. How deep does an inheritance have to go before you consider other options?
From my experience, most well-designed object-oriented classes should be at level one, ie, they should not extend any other class (not counting a fundamental base class such as java.lang.Object). Such classes should be declared as "final" (final in Java, sealed in C#).
A minority of classes will be designed as base classes. They will typically have subclasses at level two in the inheritance tree. Usually, they have a number of protected methods, some of which are overridable (virtual, non-final) and others not (final, non-virtual). For example, a class implementing the Template Method design pattern will normally make the template method itself non-overridable.
Any additional subclasses (at level three and beyond) should be rare. I would recommend to avoid anything beyond a depth of three, unless you are using an existing library such as Java Swing which was designed to require deeper inheritance levels (which doesn't mean the design of Swing is good).
In any case, any class which is not meant to be used as a base class should be declared as final/sealed, in order to prevent or discourage inheritance abuse.
These recommendations are in line with recent books that discuss OO and API design, such as "Effective Java", "Practical API Design", and "API Design for C++".
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 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 am having a very strange question, although I am learning OOPS through C++ since last few months. That why there is a need of a construct like class?
There is no need for classes in object-oriented programming. There are lots of languages which do just fine without them: Self, Io, Ioke, Seph, Slate, NewtonScript and ECMAScript have only objects, no classes. Other languages have mixins. Yet other languages have traits. Some languages have classes and mixins, some classes and traits.
The only thing you really need for object-orientation is some way to perform procedural abstraction. That's it. Lambda Calculus is a perfectly fine OO language, in fact, since it has only procedural (well, actually functional) abstraction and nothing else, one might argue that Lambda Calculus is the purest OO language of all.
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 9 years ago.
Improve this question
I've been reading Wirth's books on Oberon--or at least trying to--and I'm hitting a mental road block when it comes to figuring out what is going on regarding object oriented programming in Oberon.
I know his method is supposed to simplify object oriented programming by avoiding "standard" OOP syntax, which he labels a perpetration, as if it was somehow criminal, and maybe I'm just too rooted in class, method, etc... kind of thinking, but can someone translate Oberon's method into standard OOP language, or at least conceptually explain it.
You may get some insight by comparing Ada's tagged type, examined in Ada 95 Rationale: II.1 Programming by Extension, with Oberon-2's type tag, discussed in Object-Oriented Programming in Oberon-2: Run-Time Data Structures, cited here. Both use a record structure with hidden type information to implement inheritance and polymorphism. See also A Comparison of the Object-Oriented Features of Ada 95 and Java, cited here.
Addendum: So are they simply associating procedures with records?
An Oberon record type encapsulates both procedures and data, in a manner similar to the object type in Object Pascal. An Ada tagged record encapsulates the data, while the enclosing package encapsulates the subprograms and record.