Design Patterns: Elements of Reusable Object-Oriented Software

Author: Ralph Johnson, Erich Gamma, John Vlissides, Richard Helm
4.5
All Stack Overflow 198
This Year Reddit 49
This Month Stack Overflow 2

About This Book

Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalog of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselves.

The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently.

Each pattern describes the circumstances in which it is applicable, when it can be applied in view of other design constraints, and the consequences and trade-offs of using the pattern within a larger design. All patterns are compiled from real systems and are based on real-world examples. Each pattern also includes code that demonstrates how it may be implemented in object-oriented programming languages like C++ or Smalltalk.

Design Patterns: Elements of Reusable Object-Oriented Software

4.5

Review Date:

Comments

by anonymous   2018-08-06

Decorator adds responsibilities for an object dynamically. Let's say we need to count the number of times an item is added to a Set (a kind of instrumentation detail). We have Set interface in java and we can implement a decorator to add the instrumentation behavior to an existing Set implementation like so.

public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount() {
        return addCount;
    }

}

public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;

    public ForwardingSet(Set<E> s) {
        super();
        this.s = s;
    }

    @Override
    public int size() {
        return s.size();
    }

    @Override
    public boolean isEmpty() {
        return s.isEmpty();
    }

    @Override
    public boolean contains(Object o) {
        return s.contains(o);
    }

    @Override
    public Iterator<E> iterator() {
        return s.iterator();
    }

    @Override
    public Object[] toArray() {
        return s.toArray();
    }

    @Override
    public <T> T[] toArray(T[] a) {
        return s.toArray(a);
    }

    @Override
    public boolean add(E e) {
        return s.add(e);
    }

    @Override
    public boolean remove(Object o) {
        return s.remove(o);
    }

    @Override
    public boolean containsAll(Collection<?> c) {
        return s.containsAll(c);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        return s.addAll(c);
    }

    @Override
    public boolean retainAll(Collection<?> c) {
        return s.retainAll(c);
    }

    @Override
    public boolean removeAll(Collection<?> c) {
        return s.removeAll(c);
    }

    @Override
    public void clear() {
        s.clear();
    }

}

There are lot more examples for Decorator pattern that you better take a look. For an instance, say you are developing Window based GUI application. You may need to add borders to the window, a scroll bar and so on. Some times you may need to add any combination of those. That is a good use of Decorator pattern as stated in the famous Design Patterns book [1] by Gamma. I would suggest you read this book [1] to find more about design patterns.

[1] https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

by xbrandnew99   2018-03-19

Design Patterns: Elements of Reusable Object-Oriented Software doesn't use JS for it's examples, but is highly regarded in learning design patterns.

Also, Mastering JavaScript Design Patterns is pretty good, and if I recall correctly, is modeled after the first book I mentioned. Heads up, there is a more up to date 2nd edition of this book available (linked version is 1st edition)

by rjcarr   2018-03-19

Not some book, but the book:

https://toptalkedbooks.com/amzn/0201633612

Again, not saying you need to read it cover-to-cover, but if you didn't even know it existed then that's likely a problem.

by BlueCoatEngineer   2018-03-19

kicks chair back to glance at shelf


Electronics:

The Art of Electronics, 3rd edition (Horwitz/Hill)

Learning the Art of Electronics (Hayes/Horowitz)

*Signal Integrity - Simplified (Bogatin)

Debugging - 9 Indispensible Rules... (Agans)

Software:

The C Programming Language (Kernighan / Ritchie)

The Practice of Programming (Kernighan / Pike)

Clean Code: A Handbook of Agile Software Craftmanship (Martin)

Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, et al)

Computers:

*Computer Architecture, Fifth Edition: A Quantitative Approach (Hennessy / Patterson)


Note the repeated author names. :) Some of these might be a little beyond you since you're a freshman. I put a star in front of the ones that you might want to wait on until you've got more fundamentals built up. You don't have to wait for your school to teach them to you though.

A great way to jump-start your knowledge is to buy an Arduino experimentation kit (like Adafruit's ARDX) and learn how to use it. You'll get to play with where the code meets the hardware and you'll learn enough electronics knowledge to go all sorts of different directions.

Edit: almost forgot; teach yourself to draw like a mechanical engineer. There's likely an into to mechanical drawings course for the frosh Mechos, take it if you can. It comes up more often than you'd think and it'll help you learn to effectively communicate ideas visually.

by anonymous   2018-03-19

It is good that you have started organizing your code into objects, this is a good move into the better application structure. Once when you start looking deeper into it, you will find ways to split your current objects into even smaller parts and organize them in better ways, having less code solving more problems in more flexible ways.

For example, in your code the business logic is still tightly coupled to the database. What if you decide to use mysqli instead of PDO? You'll have to touch every class in your application.

But if the database interaction was extracted into own set of objects that were used by your business logic, it would be much easier to replace the database access layer. In fact, you could quite easily replace MySQL with PostgreSQL or even with plain files in that case.

I can think of two ways to learn more about how OOP works: read a book or learn from the existing code.

The book I linked is my favorite OOP book and shows some very good examples of how the problem can be solved with OOP by decomposing the program into the co-operating objects.

And I'd also recommend starting using some OOP framework, I had some good experience with Yii in the past, check the guide to see how it looks like. You'll see tons of useful objects solving various problems you have to solve all the time when developing a web application. Try to build some simple application with it and then try to look inside the framework code to see how it actually works.

One more advice is to look into automatic testing. This will not only keep your application alive, but will teach you how to compose better objects. You'll have to use your classes in two different situations - your actual code and tests. Inside tests you will want to isolate the object you are testing from the rest of the code, for example, test the sales stats algorithms without touching the database. And you'll have to split you code into smaller and more flexible structure to be able to do that.

by Michael Stum   2018-03-19

Big List of Resources:

Legend:

  • ¶ Link to a PDF file
  • $ Link to a printed book
by anonymous   2017-11-27
Re, "Is there some design pattern involved in...?" It _is_ a design pattern. A design pattern is any way of doing something that is replicated by lots of developers. The purpose of the original [Design Patterns book](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/) was to teach us to give them names so that we may more easily talk about them. I don't know if there's a better name, but most developers would know what I was talking about if I said, "...create a thread with a `Runnable` _delegate_."
by gnufied   2017-08-20
What i listed was just an example but you can verify quickly - https://www.amazon.com/dp/0201633612/?tag=devbookscom20-20 without opening the actual book.

And afaict - none of the patterns I listed are mentioned verbatim.

by PaulKeeble   2017-08-20
The classical Design Patterns book has a first chapter which takes you through the design of a text editor using the patterns provided in the book. If what you do is read the chapter and then the patterns referenced as you go and build the text editor based on their design you get exactly the sort of thing you are looking for. Its a different way of doing it than the entire book but arguably just in a different format for what is otherwise a reference book.

https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...

by anonymous   2017-08-20

No, that does not violate any OOP principle.

A prominent example is an object who's behavior depends on whether a connection is established or not (e.g. function doNetworkStuff() depends on openConnection()).

In Java, there is even a typestate checker, which performs such checks (whether Duck can already Quack()) at compile time. I often have such dependencies as preconditions for interfaces, and use a forwarding class whose sole purpose is protocolling and checking the state of the object it forwards to, i.e. protocol which functions have been called on the object, and throw exceptions (e.g. InvalidStateException) when the preconditions are not met.

A design pattern that handles this is state: It allows an object to alter its behavior when its internal state changes. The object will appear to change its class. The design pattern book from the Gang of Four also uses the example above of a network connection either being established or not.