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.
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 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?
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 wondering if there's an accepted/idiomatic way of testing an unexpected behavior when working with external systems (such as databases). These are mostly cases within "if err != nil {...}", when normally the error just doesn't happen and you don't control it through the inputs.
One "right" way of doing that is probably defining an interface and a mock structure that would return error when you need it. But if I already have a significant amount of code that doesn't work with interfaces, bringing them just for the sake of testing a couple of scenarios seems tiresome.
So does anyone know and use different approaches? For example, in dynamic languages such as php and js a function/method behavior can be easily overridden with a mocking library or even manually, which is quite useful when writing tests.
Using interfaces and custom / mocked implementations for testing is the way to do this. If you want to test most of your code, it is worth making the switch now. If you don't want to test most of your code just a tiny part of it, then what's the point of even bothering with the test? They won't ensure you of anything, on the contrary, they will give you the–false–illusion that "everything" is fine.
If you don't want to use and mock interfaces, another way would be to mock the database server itself, but let's face it, it would be even more work.
Just use interfaces. It's never too late to refactor. It is something always worth doing on the long run.
Also note that you can do this "switch" gradually. Just create an interface that contains the functionality used by the code you want to test. You don't need to "touch" the rest of your code. Change the testable code to use the interface, which then you can mock in your tests. This is easy in Go.
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 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.