Code reuse

S

Simon

Hi all,



I'm hoping that some of you clever chaps could offer me some advice on code
reuse.



You see, whenever I make applications, I typically only find very limited
scope for code reuse. I also only find limited use for inheritance. For
example, the various types of users that my system might have to deal with.



I'm wondering if anyone could give me some tips on how to identify areas of
my design that could be reusable, where I can use inheritance and where to
use interfaces. I've read all the books that talk about why these things are
important but very few of them show you how to do it in the real world.



If anyone could point me to some online resources on this then that would be
great. I could also do with a couple of books on how to spot reusable
aspects of my designs and so on.



Any help would be great



Thanks all



Simon
 
B

Ben de Vette

Simon,

normally it is not hard to see where the reuse is put.
It is not only in making a dll with common used methods or functionality,
but also the logical way of thinking in objects.

There are two kinds of reuse:
- Reuse within an application
- Reuse through several applications

Reuse within an application can be achieved by use of common methods and
behaviour in supperclasses,

Reuse through several applicatioons can be achieved by writing your code in
such a manner that it is application independant.

For instance, when you have three types of users in your system. Say:
- A Superuser
- A normal user
- A dummy user

they can be seen as three instances of the same user. Atributes makes the
difference between them. In this case you will have little reuse within the
application, because they all share the same class. But this class,
providing this behaviour, can be used within several applications.

In the case where the three users are defined as a subclass of user, all the
common functionality is put into class User (which is never to be
instanciated) while all the differences between the users are defined in the
subclasses : Super-user, normal user and dummy user. This can be seen as
reuse within an application. Again, this whole structure of user types can
be reused in almost every application you write.

The same is true for database access. If you write it once in a way that it
is not specific for a certain application, it can be reused over and over
again.

Another reuse is the use of design patterns. They are not really reuse of
code, but reuse of the way you approach problems which look very simular.

Greetz,
Ben
 
R

Radek Cerny

Why force code re-use? Start with design reuse, and code reuse will fall
out naturally.
 
K

Kevin Spencer

You asked specifically about 2 things: Inheritance and Interfaces. Let's
start with Inheritance, as that is the easiest to understand.

In Object-oriented programming, you have classes that encapsulate
functionality, rather than functions existing outside of any class. In
procedural programming, you have what is called function libraries, for
re-usable functions. Function libraries are DLLs, but they contain only
functions, not classes. In OOP, you have classes that encapsulate
functionality. For re-usability, you can use inheritance. For example, let's
talk about System.Web.UI.WebControl. All WebControls inherit this class.
Why? Because they all have some things in common. By creating a base class
that contains all the functionality that is shared by these classes, you
re-use the base class and its functionality in each derived class. For
example, all WebControls have an Attributes property, because all HTML
objects have attributes. By encapsulating this in a base class, you don't
need to re-write the code for each derived class, and if there is a need to
change this functionality, you change it in one place (the base class) and
all derived classes inherit that functionality.

Interfaces are a bit different. They define a "contract" if you will, that
specifies certain characteristics that are required by any class that
implements the Interface. These characteristics are either fields,
properties, or methods, which must have a certain signature. For example,
when creating a Server Control that implements IPostBackEventer, you must
implement a method called "RaisePostBackEvent." Why? Because, in order for
the class to handle PostBack events, it must have a method which can be
called from outside the class, which conforms to the signature of the
RaisePostBack method in the IPostBackEventHandler contract. In other words,
there is an external dependency in the architecture, which expects to find a
method with that signature.

Does that help?

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top