Object-Oriented Software Construction (Book/CD-ROM) (2nd Edition)

Check out "Object Oriented Software Construction" by Bertrand Mayer.

The concept is called "Contract Driven Development" It's an in-line type of testing at a function level, it's changed the way I program.

If you use CDD in Eiffel, the language also written by Bertrand, they're automatically checked by the runtime during the test and debug phase.

http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554

http://dev.eiffel.com

http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554

Object Oriented Software Construction - Betrand Mayer

He's the man that originated the Eiffel language, the most complete analysis of OO software construction I've read.

Read Bertrand Meyer's OOSC2. It's probably the best book ever on OO programming.

the main topics that one should learn are: * some tidbit of history on why oop * fundamental object oriented concepts: inheritance, encapsulation, and interfaces * network of objects and their restricted interactions

* modeling a domain using objects * documenting objects and their interactions * how are objects represented in memory * SOLID principles * solutions (design patterns) to common problems * concurrent design and thread safety in oop designs * tools in oop design (CRC cards, UML, etc.) * actually making projects and laying out the code in an implementation language.

Here are some books I seem to like so far.

books:

Holger Gast - How to Use Objects: Code and Concepts (https://www.amazon.com/gp/product/0321995546) This book seems to be what I was looking for. It has an integrated practical approach using the Eclipse source code as examples for various object oriented concepts. I have cross-checked various sources and it seems like this book covers all relevant concepts including SOLID principles.

Bertrand Meyer - Object-Oriented Software Construction https://www.amazon.com/Object-Oriented-Software-Construction... This seems to be a great reference. However, I haven't looked too thoroughly into it. I found a nice quote though.

  "Today, no one will call security if one of the cocktail guests 
  declares object-oriented tastes. This is the buzzword effect, which 
  has been dubbed mOOzak: the omnipresence, in the computer press, of 
  O-O this and O-O that, causing a general dilution of the concepts. 
  The words flow so continuously from the loudspeakers — object, 
  class, polymorphism... — as to seem familiar, but are the concepts 
  widely understood? Often not." (29.1)

Do you mind expanding on this a little bit? I am very confused. A "data structure" is an implementation of an abstract data type (https://www.amazon.ca/Object-Oriented-Software-Construction-... page 165).

I am not sure how you can have a data structure Book without any operations. Even if it were a C struct, accessing a field would consist an operation around that data structure.

Basically, this cannot be done using C#, as has been said by several posts in this thread. It has been argued that this is not proper OO, but I beg to disagree. For ease of reference, if you have it handy, check page 464+ of OOSC. The term to be used here is Invariant inheritance. The example given is a Rectangle (always four sides), inheriting from Polygon (any amount of sides larger then 2).

The rule is simple, quote:

The invariant property of a class is the boolean and of the assertions appearing in it invariant clause and of the invariant properties of its parents, if any.

Bertrand Meyer uses Design By Contract. To a lesser extend this is available to C# as well. With .NET 4.0, it has become available through Spec#.

About the argument that this is not proper OO: the argument is correct (preventing inheritance down the chain defies the contract), but without preventing inheritance, but adding restrictions on the values by using invariant clauses, the OO paradigm is saved and the inheritance chain remains intact. Something like this:

abstract class Animal
{
    public abstract Legs { get; }
}

class Dog : Animal
{
    public Dog { } 

    [InvariantMaximum(4), InvariantMinimum(4)]
    public override Legs { get { return 4; } }
}

class Labrador : Dog
{
    public override Legs { get { return 5; } }    // compiler error
}

class Chihuahua: Dog
{
    public override Legs { get { return 4; } }    // OK
}

Edit (solution with sealed, a follow-up on this)

As requested in one of the threads, here's a little example that works with sealing off the further inheriting of a member (something many here considered a breach of OO, while the language designers clearly understood that it isn't):

public abstract class Animal
{
    public abstract int Legs {get;}
}

public class Dog : Animal
{
    public sealed override int Legs {get { return 4; } }
}

public class Labrador : Dog
{
    public override int Legs { get; }    // compiler error
}

In addition to using an enum in your specific case, from a more general perspectice, you might take a look at (by no means inclusive -- there's more than one way to do it) these:

• Data Annotations. Attribute-based validation.

• Microsoft Research's Design by Contract extensions for C#: https://stackoverflow.com/a/267671/467473.

  You can install the Visual Studio extension at http://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363-46c9-851f-1ce455f66970

Here's an article by Jon Skeet on code contracts: http://www.infoq.com/articles/code-contracts-csharp.

The ur-text for design-by-contract — and arguably the best overall book on O-O design — is Bertrand Meyer's Object-Oriented Software Construction, 2nd ed.. The Eiffel language has design-by-contract at its core: Eiffel/Eiffel Studio is a full-fledged Eiffel IDE that produces CLR-compliant assemblies.

High cohesion within modules and low coupling between modules are often regarded as related to high quality in OO programming languages.

For example, the code inside each Java class must have high internal cohesion, but be as loosely coupled as possible to the code in other Java classes.

Chapter 3 of Meyer's Object-Oriented Software Construction (2nd edition) is a great description of these issues.

Chapter 6 of "Practical API Design" by Jaroslav Tulach is titled "Code Against Interfaces, Not Implementations". It explains that, by coding against an interface rather than a specific implementation, you can decouple modules (or components) in a system and therefore raise the system quality.

Bertrand Meyer in OOSC2 explains clearly why "closing" a system and making it more modular raises its quality.

1. "Object-oriented software construction" by Bertrand Meyer

Most fundamental work about object-orientation ever published. This is absolutely must have book for every "object-oriented" programmmer.

2. "Object-Oriented Analysis and Design with Applications" by Grady Booch et al

Not so formal as Meyer's book, but this book can open your eyes on many questions in object-oriented world and in software development in general

3. "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma et al.

This is famous "Gang of Four" book about design patterns

4. "Refactoring: Improving the Design of Existing Code" by Martin Fowler et al.

This is another classical book. First part perfectly describe many problem that modern software developer may faced during his work: code smells, readability vs performance, premature optimization drawbacks and many other topics.

5. "Thinking in Java" by Bruce Eckel

This book may help many beginners not only in Java language but in object-oriented way of thinking too.

6. "Touch of Class: Learning to Program Well with Objects and Contracts" by Bertrand Meyer

Excellent textbook by famous author.