Software design has as a fundamental problem being able to express yourself in a way that is clear and remains clear as things change. Basic principles of good software design, like reducing cohesion, remain good principles no matter what "paradigm" you think you're using. When you change paradigms, be aware that the basic principles remain the same no matter what label you give them. And since design is all about tradeoffs, if you are going to have to violate a principle, you might as well do it in the clearest and most straightforward way possible.
Let me give an example. A singleton is bad for all of the reasons that a global variable is bad. If you need one, I prefer to make it a global variable simply because that is honest about what design principle has been broken. (Unless I want to make it lazy - then it is easier to write with a singleton!)
So learn the principles. Figure out what they look like and are called in your paradigm. Get on with life and solve real problems.
Let me give a concrete example. I learned more about good OO design from the first edition of Code Complete than any other book that I ever read. Even though it was entirely about procedural programming. Because the principles that it discussed, from how to name functions to the value of abstract data types to information hiding, all apply directly to OO. And to functional programming. And to aspect oriented programming. They are truly universal. Learn the principles, they are more important than the labels.