Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
SOLID Software and Design Patterns for Mere Mortals
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Phil Japikse explains SOLID software principles - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion- and how to apply them using design patterns.
Bio
Phil Japikse is a Microsoft MVP and also holds MCSD, MCDBA, CSM, and CSP certifications. He has spoken at Code Camps and Days of .NET and is the Lead Director for the Cincinnati .Net User’s Group. Phil works as the Patterns and Practices Evangelist for Telerik (www.telerik.com). You can follow Phil on twitter via www.twitter.com/skimedic and read his blog at www.skimedic.com/blog.
About the conference
Code PaLOUsa is a conference designed to cover all aspects of software development regardless of technology stack. It has sessions revolving around Microsoft, Java, and other development platforms; along with session on higher levels that are platform agnostic. The conference schedule will feature presentations from well-known professionals in the software development community.
Phil Japikse explains SOLID software principles - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion- and how to apply them using design patterns.
Bio
Phil Japikse is a Microsoft MVP and also holds MCSD, MCDBA, CSM, and CSP certifications. He has spoken at Code Camps and Days of .NET and is the Lead Director for the Cincinnati .Net User’s Group. Phil works as the Patterns and Practices Evangelist for Telerik (www.telerik.com). You can follow Phil on twitter via www.twitter.com/skimedic and read his blog at www.skimedic.com/blog.
About the conference
Code PaLOUsa is a conference designed to cover all aspects of software development regardless of technology stack. It has sessions revolving around Microsoft, Java, and other development platforms; along with session on higher levels that are platform agnostic. The conference schedule will feature presentations from well-known professionals in the software development community.
RelatedVendorContent
Architectures You've Always Wondered About @QCon New York
Systems Engineering for Dummies eBook
Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns
Why NoSQL? A Primer on the Rise of NoSQL
Introducing SQLFire: a memory-optimized, high performance SQL database
Barbara Liskov is a "she"
by
Chris Sutton
Posted
ok...
by
Ranjix ranjix
Posted
Re: ok...
by
Ranjix ranjix
Posted
Re: ok...
by
Edson Chavez
Posted
Re: ok...
by
Ranjix ranjix
Posted
video is slow in China.
by
Meng Jian
Posted
Double Checked Locking might be broken
by
Fernando Cardoso
Posted
Re: Double Checked Locking might be broken
by
Luis Espinal
Posted
-
en.wikipedia.org/wiki/Barbara_Liskov
Barbara was referred to as a "he" several times during this talk. -
1. for the "many methods with 4-5 lines of code", answer shouldn't be "well, what you want, a method with thousands lines of code", there is some granularity between the 2 extremes described, the talent is in finding that balance between size (of methods) and number (of methods), in such way that the balance still makes sense (semantically) and the code is readable.
2. "make a method do ONE thing well" is ambiguous. A method which calls 2 methods that each do ONE thing well, will do TWO things, unless you define doing the 2 things as doing 1. Maybe for you it's clear what you mean, sorry, for me isn't.
3. instills a fear of change which shouldn't really exist, the changes are the only constant thing, right?
5. the liskov principle is a nice one, nobody actually implements it as it's stated (possibly Eiffel, with the postconditions). Overriding shouldn't be allowed in case the principle is enforced (the behavior of a method between child and parent classes differs, hence they can't really be "substitutable").
6. there is a good undertone of "think before you apply".
7. the rest is ok, but again, unconvincing.
Just my 2 cents. -
for some reason I deleted the 4. in the above list.
4. "no plans survive the first battle", the same applies to all the "smart, beautiful, elegant" APIs I ran into, after a while (think years) they became ugly, tired, useless and in general obnoxious. -
Does infoq use any CDN?
-
about 2: Uncle Bob wrote in clean code book : "if a function does only those steps that are one level of abstraction below the stated name of the function, then the function is doing one thing. After all, the reason we write functions is to decompose a larger concept (in other words the name of the function) int a set of steps at the next level of abstraction"
Regards
Grubhart -
well, both the presenter and uncle bob are right (and I actually do understand what the presenter stated), unfortunately the wording is not great in either case. In case of the presentation, is not the "number" of things that is the problem ("that number must be 1"), but is the purpose of things which matters, a method should do only and strictly what's required of it and nothing else ("what's required" is a different issue which needs a better definition). In case of uncle bob (how is uncle bob?), is difficult to think in terms of "how many levels of abstraction" are between certain things, and make sure that the number is 1, so it's not really helpful either (for example, how many levels of abstractions are between a method that saves an object and a method that calls a SQL statement? my personal answer is "who the hell knows?").
IMO in both cases someone tries (too hard) to extract some smarty-pants "principles" from a fairly down-to-earth example, and, in doing so, lose or hide the meaning. -
For Java, one should keep in mind that this double checked locking for Singleton creation might be broken.
www.cs.umd.edu/~pugh/java/memoryModel/DoubleChe... -
For Java, one should keep in mind that this double checked locking for Singleton creation might be broken.
www.cs.umd.edu/~pugh/java/memoryModel/DoubleChe...
Uh, that was solved almost 8 years ago with Java 5.
8 comments
Watch Thread Reply