0

I am trying to maintain proper code organisation for my codebase. I came across a situation whereby organising my code into class A, B, C is unnecessary as class C can be incorporated into class A and B. This is because the functionalities in class C are from a library which means the functions have been wrapped nicely. Class A could be a thread that does callbacks, class C could be like a class that solely does processing. Basically, should I strictly follow the Single Responsibility Principle? What are the pros and cons of doing each method? I hope this is the right place to ask such questions.

2
  • 5
    No matter what anyone says, there is no strict rules that govern what is correct OOP and what isn't. There only is a lot of guidelines of what generally makes sense and what doesn't. To give you concrete advice for your specific situation you should describe your problem in more detail. How are A and B using C and would you ever change the way you use the external library or exchange it for another one? If you were to change the library, would that affect A and B at the same time or could only A or only B be changed?
    – Helena
    Jun 18, 2021 at 12:25
  • 3
    @Helena: OOP is here only a red herring, the OP mixed up "making a wrapper class for encapsulating a library" with "OOP"
    – Doc Brown
    Jun 18, 2021 at 12:54

1 Answer 1

-3

So thanks to the link by Doc Brown, I am going to summarise what i have learnt: I would like to use two factors to decide

  1. Scalability
  2. Dependency

Scalability

If your codebase is something that is supposed to be maintained for a long period or if it is a throwaway program would decide if you should use a strict Single Responsibility way of organising. In the case of it having to be maintained, it is recommended to wrap all the functions to customise to your code's objective and needs. This is because a third-party library is not customised to your needs all the way to the finest details. In the future, if you want to improve on the code, you can easily replace the libraries with better libraries or write your own optimised code. Also, it is easier for people to read as they do not need to look up those library APIs and simply need to refer to your code directly to understand what is going on.

Dependency

If your code is highly dependent on those functionalities from the library you are using (in class C), you should always organise your code with each class performing a certain group of functionalities, even if it may seem to slow you down because it is easy to trace a problem when your code base gets too large. Also, it gets messy/untidy to read when a lot of those functionalities are incorporated. I would say this point can be subjective and when in doubt, just adopt a clear, organised way to think about the program, especially when coding with others.

5
  • 1
    I think you need to think about this some more. Some of your conclusions seem suspect. Better yet, just get more experience writing actual code; over time, you'll get the sense of which techniques work best in specific situations. Jun 18, 2021 at 14:51
  • Let me add something which I already wrote in a comment to your question: "strict OOP design" is something pretty different than "making a wrapper class for encapsulating a library". Actually, these two things are mostly orthogonal. This answer here, however, mixes these two terms up and uses "OOP design" as a alias for "wrapping a library" (even more than the question). I would recommend considering an edit of your answer, having this distinction in mind.
    – Doc Brown
    Jun 19, 2021 at 5:20
  • @DocBrown could you specify? I was under the impression that encapsulation is a core part of the OOP paradigm. The wrapping of a library would be to make my codebase more object oriented by having distinct classes that do not perform functionality which does not align with their nature. How are they orthogonal?
    – Iberico
    Jun 19, 2021 at 5:44
  • @Iberico: sounds like a classic logical fallacy - encapsulation is a surely core part of OOP, nevertheless doing some encapsulation does not mean one does OOP automatically (even when making use of classes). One can wrap a library with a class by using mainly static functions in a purely procedural manner, or even in a functional manner. It is also possible to give certain libraries an object-oriented wrapper, but that's not mandatory (and not necessarily desired) when wrapping a library. This depends heavily on the lib, your intended use cases for the lib, and your preferred kind of API.
    – Doc Brown
    Jun 19, 2021 at 6:07
  • @DocBrown I see. I have already gotten the answers i need to my initial question but i definitely did not phrase the question properly, will make changes.
    – Iberico
    Jun 19, 2021 at 8:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.