http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Cool, thanks. http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment5http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment5Sun, 11 Feb 2007 04:59:20 GMTOren, Yes, there are certainly multiple avenues to approach extensibility, and I favor the template and strategy methods. I personally don't like overloading unless I can keep it to a minimum and I'm sure you are the same. I just have better luck with templates and strategies. I agree on the guidelines shouldn't be different for basic vs advanced developers but at the same time you have to provide comfort and draw a line somewhere. Some people are just getting into frameworks, and trying to spill into their heads in 2 hours what I've spent 12 years learning just doesn't make sense. As they progress, and I mentioned this in the presentation, you're much more likely to disagree with some of the things I mentioned, and that is perfectly fine and expected. Even though some people didn't speak up during the presentation, I spoke with some people afterwards who questioned some of the things and we talked about them. Its certainly best to explore what you think is right and treat guidelines as what that are: mere paths from which you should venture off of and explore its surroundings. I'm glad to hear you agree with everything else :) It'd be nice to get your feedback of the actual presentation someday, but not likely we'll cross paths on that avenue any time soon. How about you let me elaborate more on the interfaces = syntax vs abstracts = contract in a blog post so we don't draw out this thread beyond its scope? http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment4http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment4Sat, 10 Feb 2007 21:52:24 GMTThanks for the speedy reply. I thought that the last part wasn't in context, but the first one looked complete. There are two major issues here that I see: 1/ You and I have different approaches to extensibility, both are valid, but I tend to use a lot less template methods and a lot more overloading. 2/ I really don't like idea of different guidelines for advanced and basic developers. In fact, I would argue that if you are building a framework, you should be above basic at the very least. The main issue that I have with this is that there are plenty of people that are taking those guidelines and treat them as rote. I once had to deal with a system where interfaces where completely forbidden. The reason: the architect believed that interfaces were slower than abstract base classes, so they used pure virtual abstract base classes for everything. I would spare you the way they implemented multiply inheritance with generic parameters, but it wasn't fun to work with. The actually hit a few compiler bugs because of it. As I said, in the entire presentation, only those things bothered me, everything else I completely agree. That is probably a good ratio :-) I am glad to know that I didn't have full possession of the facts :-) The part about interface == syntax and abstract base class == contract is interesting, can you expand on that a bit, I don't think that I quite follow what you mean here. http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment3http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment3Sat, 10 Feb 2007 21:40:54 GMTOren, you are taking the slides out of context of the presentation in which they were presented. You needed to hear the talk that went along with it. While sometimes virtual members are required, they should be avoided if you can provide the extensibility you are looking for through a template pattern. Also, virtual members are more difficult to deal with when making changes in terms of breaking existing code and compatibility. You have to take into account any user implementations of those virtual members, and you've sealed your fate into having to support that design and poorer performance model. Naturally, there are reasons to use virtual members and most advanced programmers know what they are getting into. I was merely pushing the guideline in a course entitled "basic framework design" that if you can avoid it, do so. I certainly don't expect more advanced programmers to adhere to these guidelines (and they are guidelines, not rules) when the circumstance calls for exceptions. There are drawbacks to virtual members that may not be directly understood until you have more experience with them, and that was the point. On to the interfaces comment: again, since you didn't hear my presentation, you missed where I said that I am a big supporter of interfaces and use them throughout my code, probably too much. I also had to note that I "mistyped" what was written in the slides (I should go fix that) about the interfaces defining semantics. Semantics should say "syntax" instead. The semantics and contract are the same thing, and neither are supplied by an interface. An interface merely supplies syntax. Abstract classes should be used for separation of contract from implementation as they can be evolved and extended with much greater ease and versioned without causing breaking changes, if done correctly. Now, again, I favor interfaces personally, but I also understand exactly what I'm doing with them versus abstract classes and what I am both limiting myself to and also what I'm gaining. I expect you do as well. Again, this was a "basic framework design" presentation and I certainly wouldn't think you would argue with those guidelines at a basic level, would you? At a more advanced level? Absolutely. After all, they are just guidelines. How else would we make something both comparable and formattable and even convertible without interfaces? A base class doesn't make too much sense here, and again, without hearing the presentation itself, I can certainly understand the disagreement while viewing the deck out of context. http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment2http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment2Sat, 10 Feb 2007 21:06:28 GMTI don't get it either. What does the abstract class have that an interface can't have with regard to the contract? But then I don't think the code is the contract. Does Raymond? http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment1http://ayende.com/2096/on-the-framework-design-principles-from-raymond-lewallen#comment1Sat, 10 Feb 2007 20:52:17 GMT