In the mid 1990, there was an emerging topic of design patterns, due to the rising popularity of C++ and creation of Java. Some of them might include:
- Singleton (class that is used once)
- Factory (creator of objects)
- Prototype (the skeleton or blueprint of a class)
And here is the first problem that could arise: while working in a diverse environment, different persons might use different types of dessing patterns. For example a singleton class cannot be used as a dependency in another class. These might not be totally compatible and refactoring might be needed.
The second issue arises from the fact that OOP may not be the best solution. For small projects there is no need for operator overloading and some simple functions can get the job done. While writing C APIs it’s common to use something like an opaque struct(and the actual code hidden in a DLL).
struct _Window;
typedef struct _Window Window;
Window* win_create(char* title, size_t width, size_t height);
bool win_destroy(Window* win);
bool win_move(Window* win, size_t x, size_t y);Here, the advantages of OOP are noticeable, using win_move(mWin, 500, 400) may not be as straightforward as mWin.move(400, 500). OOP is not fully bad, but at the end if the day classes are just abstractions of C-like structs, hence compilers need to transform the class to something like above.
Verbosity can be a problem for fully OOP languages like Java. To write a simple hello world program you need to know the concepts of:
- classes
- methods, functions
- static members
In practice it looks like this:
class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
}
}In combination with obfuscation of simple operations like IO and File Management you get a language with a learning curve very steep.