You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the codebase is OOP in the sense that there are often many methods shoved into 1 class and 1 class per file which violates some common paradigms.
Classes should follow the single responsibility rule each class should do only one thing, but should do it well
Namespaces are in place put they could be used more effectively. an example:
Under the linear algebra module we might have some methods related to Signal Processing. This doesn't mean that our methods need to be shoved into 1 SigProc class but instead be separated into different classes for different techniques:
gpmp::linalg::sigproc::lpf(SIGNAL, FREQ, CUTOFF) for a standalone function OR gpmp::linalg::sigproc::LPF() for a class
there might not be enough to expand into a complex class with a few member variables and methods
The text was updated successfully, but these errors were encountered:
Signal processing methods have been removed but this point still stands for some class. For example the gpmp::linalg::Mtx class doesn't feature any OOP methods. I can't think of any benefits in doing so since these functions purpose is pretty much a 1 off.
Most of the codebase is OOP in the sense that there are often many methods shoved into 1 class and 1 class per file which violates some common paradigms.
Under the linear algebra module we might have some methods related to Signal Processing. This doesn't mean that our methods need to be shoved into 1 SigProc class but instead be separated into different classes for different techniques:
gpmp::linalg::sigproc::lpf(SIGNAL, FREQ, CUTOFF)
for a standalone function ORgpmp::linalg::sigproc::LPF()
for a classthere might not be enough to expand into a complex class with a few member variables and methods
The text was updated successfully, but these errors were encountered: