Jon Skeet: Coding Blog - All Comments

re: Book Review: Async in C# 5.0

skeet — Wed, 22 May 2013 12:58:28 GMT

@Chris: Thanks, missed that. (I wrote the review on a plane, so left all the links as FIXME, then fixed up *most* of them later.) I've added the link now.

re: Book Review: Async in C# 5.0

Chris Simpson — Tue, 21 May 2013 15:23:20 GMT

Hi Jon, thanks for the review. The play books link just goes to "fixme". Cheers, Chris

re: New tool to play with: SemanticMerge

Dim2D — Tue, 07 May 2013 16:48:49 GMT

Skeet please do blog more, you're a huge inspiration for a lot of us, I've read your awesome book and watched the tekpub vids and learned so much. Keep up the good work.

re: Fun with Object and Collection Initializers

Bill Woodruff — Wed, 01 May 2013 05:12:29 GMT

That first example of "incidental" Property initialization by use of the assignment operator, while creating an instance of an IEnumerable was surprising to me:

Weird weird = new Weird { Foo = "y" };

It wasn't surprising I couldn't access the internal collection of 'weird, since there's no "real" GetEnumerator implemented.

So, with the second call you have created a collection with 1 member, but you can't access it ! I am not sure what I am supposed to learn from that :)

What would seem to make sense to me would be that anytime I create a Class meant to be an Enumerator, that maintained some Public state Properties, which might be initialized as instances of the Class are created, that I would put a constructor in the Class to handle initialization of those Properties.

public Weird(string foo){Foo = foo;}

Then I can easily create a new instance in which the initialization of state variables, and the creation of internal Enumerable elements, is semantically distinct:

Weird weird = new Weird(foo:"some string"){"1","2"};

Or, create an instance with state variable set, but internal collection empty:

Weird weird = new Weird(foo:"some string");

That does "lock me into" having to provide an argument(s) to create an instance of 'Weird, unless I throw in an optional parameterless calling form:

public Weird(){}

thanks, Bill

re: New tool to play with: SemanticMerge

Richard — Fri, 19 Apr 2013 08:01:03 GMT

If you're looking for novel uses for Roslyn then I'd recommend using it as a code re-writing tool.

I used it do a large refactoring over 200 files. The change involved removing about 4 properties including regions and comments, inheriting from a newly created base class and passing the value of those 4 properties into the constructor for the base class.

There were a few edge cases that it didn't catch but it did the bulk of the work and I cleaned up the remaining code by hand.

If you were really ambitious I'm sure you could use it to implement a kind of compile time AOP (inserting the AOP stuff in code rather than in CIL) but I haven't had a need for doing that so I haven't looked at it.

re: New tool to play with: SemanticMerge

Luis de Santiago — Thu, 18 Apr 2013 21:57:24 GMT

Recently I have been interested in Roslyn, and I'm amazed about the possibilities it offers. I have in mind some search integrated in visual studio. But with semantics. R# have a little in that direction, but I think I can go way deeper.

So this one is a really awesome idea of a product. Will try to tell my comrades to use it.

By the way. Awesome book (C# in depth 3rd ed. MEAP) :)

re: The Open-Closed Principle, in review

ProfessorZ — Thu, 18 Apr 2013 15:35:59 GMT

@Haacked "Clearly it had to be called the "Open Closed Principle" to provide the "O" in "SOLID"."

Or really, how is "Liskov substitution principle" not clear to you?

re: The Open-Closed Principle, in review

Philip Schwarz — Sun, 07 Apr 2013 06:05:13 GMT

The following post by Kent Beck should help understand the Open-Closed principle:www.threeriversinstitute.org/blog

Here are some excerpts:

The Open/Closed Principle always bothered me. I agree with it philosophically–good designs make it possible to add functionality without disturbing existing features–but in my experience there are no permanently closed abstractions.

...

Ordinary design is the kind we do every day–extract a method, extract an object, move a bit of logic or state closer to where it belongs. The open/closed principle pretty much works. Superclasses sit. APIs sit. New features fit the design without much change.

Then comes a feature that really doesn’t fit the design. The fundamental elements and relationships have to be twisted to implement it. The fact (feature) just doesn’t fit the theory (design).

...

When the need for design change becomes apparent, software designers can isolate the part of the system that is to change from the part that will remain stable.

...

Revolutionizing designs without first isolating change puts a bigger burden on the designer. The challenges of revolutionizing a design while working in safe steps is generally enough for me without adding the challenge of keeping track of changes all over the code base. Isolating change is low-risk and fairly mechanical, while giving me an overview of areas of the system that are about to be overhauled.

...

Revolutionary design violates the open/closed principle, almost by definition. The feature you want to add needs new elements and relationships that don’t fit with the existing design. The basic abstractions need to be reopened to modification. Once the feature is added, they can close again. Further development can use the new elements and relationships as vocabulary for further extension. This extension takes place against a background of ordinary responsive design.

...

re: Fun with Object and Collection Initializers

Anthony Chambers — Fri, 05 Apr 2013 09:13:32 GMT

Interesting. I thought that you were saying weird.Foo was somehow being set to null in your last example (the 'result' of assigning a value to the local variable). But when I gave Weird.Foo a default value of "a" it remains as "a", which is what you were saying all along!

re: C# in Depth 3rd edition available for early access, plus a discount code…

John — Wed, 27 Mar 2013 01:44:43 GMT

I had your book, CLR via C# and Expert C# 5.0 (new book but with some interesting information). My collection is about to complete :)

re: The Open-Closed Principle, in review

Philip Schwarz — Sun, 24 Mar 2013 00:38:44 GMT

Free screencast: Refactoring to the Open-Closed www.netobjectives.com/.../refactoring-to-open-closed

re: The Open-Closed Principle, in review

Richard Smith — Tue, 19 Mar 2013 00:52:37 GMT

I'm delighted that u never fully "got" OCP either.

It did seem that an awful lot of people were repeating this mantra like (cough...cutting and pasting from the original source), and not really getting it themselves either!

The PV explication makes much more sense to me.

re: The Open-Closed Principle, in review

Michael Hunter — Mon, 18 Mar 2013 22:25:25 GMT

You mention that in the Shape example there is only predicted variation. I would argue though, that the example also implicitly predicts something that won't vary: the operations that can be done on a shape (eg "Draw"). If the point/location of variation was not "what shapes there are" but rather "what operations can be done on a shape" then the DrawAllShapes with a switch statement is clearly the better solution. It is OPEN for EXTENSION [of functionality] because new operations can be added (eg create a "measure area" function) and CLOSED for MODIFICATION because new shapes can't be added easily. In other words, it's not just a case of "more" or "less" variability, but also where you put it. In this case one type of variability sacrifices another type. You have to decide at design time whether the program is more likely to expand with new types of shapes, or new operations on a fixed set of shape types.

re: The Open-Closed Principle, in review

Keith Nicholas — Mon, 18 Mar 2013 02:07:47 GMT

Really worth reading Object-Oriented Software Construction, and understanding Bertrands ideas on OOP. Back in the very early 90s I learnt OO using Eiffel. As I see it, the ideas of OCP marries up with Design By Contract for making robust modular software (as well as other principles). The idea being you make these ecosystems of objects (which Eiffel was really big on) which have well defined thoughtfully designed contracts, you can then build on these objects to make more complex systems. It's essential that these objects are well designed and stable, and hence conform to OCP. This is because you want to be able share these objects as a base for many kinds of software systems so other people can build robust software with whatever you come up with. So the code should be closed to change, except when there was bugs, but in general if you have well designed contracts, your software should be quite robust. Its like an engineering approach to software where you'd end up making these well designed objects that are **eternally** useful made to a particular specification and tolerance that were usable as parts in a bigger machine.

The reality is, from greenfield, designing software like this was quite difficult. Implementation inheritance was a popular way to "extend". Messes were made. So what was needed was a lot more practical advice on OO designs that worked well, the principles were too broad (but guiding). Then slowly practical advice appeared over the years. The GOF patterns being of a major practical help, and then eventually unit testing as a practical way of having executable coding contracts, and Refactoring for a way of morphing software without having to get it all correct with engineering precision upfront. Then with this base, in the 2000s a massive melting pot of ideas came along.

However, the core principle of OCP lives on..... just having various postmodern reinterpretations :)

re: The Open-Closed Principle, in review

skeet — Sun, 17 Mar 2013 13:50:29 GMT

@Philip: As I said before, I don't think the comments here are a good medium for actual discussion. I don't think it would be fruitful for me to try to reply to you point by point here.

I suggest you either start a Discourse conversation (and include a reference here) or let me know if we're likely to be at the same conference at any point - a conversation is likely to be much more fruitful.

However, I'd ask you to keep bearing in mind that we're talking about a principle which many, many people will hear about *without* having read every other thing that the authors have written about. If a summary gives the wrong impression until you're read not just the single paper in front of you but also umpteen other books, I'd still say it's a bad summary.

re: The Open-Closed Principle, in review

Philip Schwarz — Sun, 17 Mar 2013 13:30:28 GMT

Jon, you said: "Likewise the meaning of "open for extension" seems unusual to me. I'd argue that the intuitive meaning is "can be extended" – where the use of the term "extended" certainly nods towards inheritance, even if it's not intended meaning. If the idea is "we can make the module behave differently" – as Uncle Bob's description suggests – then "open for extension" is a very odd way of expressing that idea."

Could it be that the reason you strongly associate the word extension/extending with inheritance is because:

(1) In Meyer's formulation of the OCP, implementation inheritance plays a key role

(2) languages like Java and C# use the keyword 'extends' to signify implementation inheritance?

Let me elaborate on these two points.

(1) While implementation inheritance is central to Meyer's formulation of the OCP, in Robert Martin's formulation, the role of implementation inheritance is almost completely eliminated in favour of interface inheritance, in the same sense that the Gang of Four's design patterns are largely about replacing implementation inheritance with interface inheritance.

In ASDPPP, Martin says that the Template Method pattern, and the Strategy pattern are the most common way of satisfying the OCP. Template Method is less desirable because it one of the few patterns that uses implementation inheritance (in Martin's words in ASDPPP: it only conforms to half of the DIP principle). Startegy is more desirable because like the majority of patterns it uses interface inheritance (it fully conforms to the DIP principle).

Just in case you have not read the 'Class versus Interface Inheritance' section in the GoF's Design Patterns book, here is my summary:

* It's important to understand the difference between an object's class and its type.

* An object's class defines how the object is implemented (state and operation-implementation).

* An object's type only refers to its interface - the set of requests to which it can respond.

* An object can have many types, and objects of different classes can have the same type.

* Because a class defines the operations it can perform, it also defines the object's type.

* Languages like C++ and Eiffel use classes to specify both an object's type and it's implementation. Smalltalk programs don't declare the types of variables.

* It's also important to understand the difference between class inheritance and interface inheritance (or subtyping). Class inheritance defines an object's implementation in terms of another object's implementation. In short, it's a mechanism for code and representation sharing. In contrast, interface inheritance (or subtyping) describes when an object can be used in place of another.

* It's easy to confuse these two concepts, because many languages don't support the distinction between interface and implementation inheritance. In languages like C++ and Eiffel, inheritance means both interface and implementation inheritance. [...] In Smalltalk, inheritance means just implementation interface.

* Although most programming languages don't support the distinction between interface and implementation inheritance, people make the distinction in practice

* Many of the design patterns depend on this distinction.

In Robert Martin's formulation of the OCP, we use mainly interface inheritance (but not exclusively - there are some cases in which implementation inheritance is used) to extend the behaviour of a class by adding new code rather than modifying the class.

(2) In Dale Skrien's great book, "OO design using Java" (btw don't be put off by the word 'Java'), he says that one way to measure the quality of a design is to analyse s/w with regard to the following properties, which he calls "the criteria for elegant software":

USABILITY - is it easy for the client to use

COMPLETENESS - does it satisfy all the client's needs

ROBUSTNESS - will it deal with unusual situations gracefully and avoid crashing?

EFFICIENCY - will it perform the necessary computations in a reasonable amount of time and using a reasonable amount of memory and other resources?

SCALABILITY - will it still perform correctly and efficiently when the problems grow in size by several orders of magnitude

READABILITY - is it easy for another programmer to read and understand the design and code?

REUSABILITY - can it be reused in another completely different setting?

SIMPLICITY - is the design and/or the implementation unnecessarily complex?

MAINTAINABILITY - can defects be found and fixed easily without adding new defects?

EXTENSIBILITY - can it easily be enhanced or restricted by adding new features or removing old features without breaking code?

Is it unreasonable in your mind for Martin's formulation of the OCP to use the word 'extends' in the above sense?

re: The Open-Closed Principle, in review

skeet — Sun, 17 Mar 2013 09:39:17 GMT

@Philip: Thanks for the detailed comments. I don't think this is the best medium to have a full debate about them (Discourse, perhaps?).

I still need to read through your comments more carefully (I've only skimmed so far) but one thing that nothing seems to change is that the broad statement of OCP itself is confusing, and uses words (particularly "open" and "closed") in a way which is counter to their normal uses.

As such, I wouldn't *want* to write my own explanation of OCP - I'd rather start again from scratch than try to put another set of details behind a phrasing which I feel is fatally flawed to begin with.

re: The Open-Closed Principle, in review

Philip Schwarz — Sun, 17 Mar 2013 02:24:00 GMT

Jon, you said: "Most of the principles seem pretty reasonable to me – but I've never "got" the open-closed principle"

Odd since according to Kirk Knoernschild the other principles are derived from the OCP.

E.g. #1 "We can think of LSP as an extension to OCP. In order to take advantage of LSP, we must adhere to OCP because violations of LSP are violations of OCP, but not vice versa.

E.g #2 "DIP tells us how to we can adhere to OCP...if OCP is the desired end, DIP is the means through which we achieve that end...in order to adhere to OCP, we must first take advantage of DIP."

re: The Open-Closed Principle, in review

Philip Schwarz — Sun, 17 Mar 2013 01:47:52 GMT

Jon, you said: "There's a reasonable example of a function which is asked to draw a collection of shapes: the bad code is aware of all the types of shape available, and handles each one separately. The good code uses an abstraction where each shape (Circle, Square) knows how to draw itself and inherits from a common base class (Shape). Great stuff... but what's that got to do with what was described above? How are the concepts of 'open' and 'closed' clarified?"

Does the following help at all?:

The bad code (version one of function DrawAllShapes) knows all the types of shape available, so to get the function to handle a new shape, you have to modify the function: you have to change it so that it knows about the new type. So while the bad code is open to extension, i.e. it can be enhanced so that it handles a new type, it is NOT closed against the addition of new shapes, because doing so requires you to open up the function and change it.

The good code (the second version of function DrawAllShapes) however does not know all the types of shape available. It only knows about the abstraction that is the Shape interface. To get the good code to handle a new shape, you do NOT need to open up the function and modify it. All you need to do is add new code, by writing a new class that implements the shape interface and that represents the new type of shape.

So the good code is both open for extension i.e. it can be enhanced so that it handles a new type, and closed against the addition of new types of shape, because you don't need to open it up and change it: it stays closed, but by adding new code (the new class) you extend its behaviour.

re: The Open-Closed Principle, in review

Philip Schwarz — Sun, 17 Mar 2013 00:03:01 GMT

Jon, you said: "the description of Meyer's approach to 'make a change by extending a class' feels like a ghastly abuse of inheritance to me"

Meyer is fully aware that this is a bit of a hack, in fact he says that "one way to describe the open-closed principle and the consequent OO techniques, … is to think of them as ORGANIZED HACKING...instead of a normal hack, in which A is polluted with ‘if (that_special_case) then’...the organized form of hacking enables us to cater to the variants… without affecting the consistency of the original"

Meyer does tell developers that:

(1) If you have control over original s/w and can rewrite it so that it will address the needs of several kinds of clients, at no extra complication, …you should do so

(2) The OCP principle and associated techniques are intended for the adaptation of healthy modules: neither OCP nor redefinition in inheritance is a way to address design flaws, let alone bugs. If there is something wrong with a module you should fix it…not leave the original alone and try to correct the problem in the derived module.