2

I mainly hear about people applying the principle to classes and methods, but do people also apply it to solutions/DLLs? For example, if I was writing a library to parse data from UsefulProgram, and then I had some more code that was related to UsefulProgram, should I have them in two separate libraries or just one UsefulProgramUtilities library?

Edit: I guess what I'm really asking is how should I divide my code among libraries.

1

A DLL is an implementation detail of a program. SRP focuses on logical code units:

  • A class should only model one cohesive unit of state or behavior.

  • A method should only perform one unit of work, and should typically not both return and mutate state.

But neither of these extend well to the library level. When I design a class hierarchy, I do not care if the classes are in separate DLLs, SOs, JARs, etc. only that the runtime environment can load and use the class.

To put it another way, SRP's goal is to ensure that a unit of code is not too complex. I may instantiate an object, call methods on it, pass it around, etc. but there is no equivalent for a DLL. Sure, I may call LoadLibrary() to load it manually, but that is the extent of manipulating a DLL in my program.

0

Wikipedia says that SRP affects "classes or modules," but I would be cautious when applying this principle to DLLs. DLLs are typically organized as part of an architectural scheme; SRP is one of the SOLID Principles, applied specifically to Object-Oriented Design, not software architecture in general.

The road to programming nirvana is littered with the corpses of programmers who tried to apply a programming principle to situations where it doesn't apply.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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