-3

One of the major issues that I am facing as a Website and App developer, is that certain components / features have to be redeveloped over and over again with a new project. For instance login, signup, user account settings etc with each new UI.

Is there a recommended method or a best practice (Design Pattern) to facilitate the development of the code using a 'Plug and Play' method, to facilitate the reuse in a way that I don't have to redevelop these components over an over again?

2
2

Looking for design patterns?

Design patterns are useful tools. But you should not choose them from a catalogue to solve your problems. Starting with the choice of a tool will make you a subject of the law of the instrument:

if you have a hammer in the hand, every problem will start to look like a nail.

You need to first design the reusable component. Maybe at a moment of your reengineering you’ll recognize a nail and take the hammer, and then a screw and take the screwdriver. The tool should be chosen to solve very specific parts of your design.

With design patterns, it’s the same: Try to rework the identified components to isolate them in a library with a well identified API that can be used in several projects. When doing so on your own, you'll find some coupled elements glued together. Try to understand the reason and what you should do to go further. In some cases you may recognize a close match with some design patterns you know.

Or in need for some general design principles?

Believe it or not, isolating your identified features in self-contained components is a first step towards reuse. In this regard, some more general principles aim at facilitating decoupling of conponents, in particular:

  • Your component should be open for extension (to account for special needs) but closed for modification (because if you modify the component, for a specific application, it's no longer reusable as such).
  • Your component should not depend on application-specific code. If there is some application specific dependency, you should invert this dependency, for example with dependency injection.

There are a couple of other such principles. Together they are called SOLID.

1

Yes. It’s called a library.

Code reuse isn’t about reusing code. It’s about writing code that is so self contained that theoretically it could be reused even though it rarely is.

Why do it if we’re not going to reuse it? Because self contained code is easy to read. You don’t have to think about the rest of the system because the code doesn’t know about the rest of the system.

So what do you do if you really, honestly, want to stop repeatedly writing code to solve the same problem? You publish a library. You’ll find this is even more demanding.

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.