Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

S.O.L.I.D

SOLID principles for software design
by

Daniel González

on 8 June 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of S.O.L.I.D

S O L I D Cohesion Coupling Encapsulation The Bad Rigidity Fragility Immobility Viscosity Opacity Needless Complexity Repetition Object Orientation Goals The Good The Ugly Multiple solutions Problem = Pragmatism Dogmatism Measure of how strong the responsibilities of an element are high low Responsibilities are few and intimately related Methods act on same state or are somehow connected Promotes encapsulation (beware of ease of testing) Responsibilities are many and/or not so related to each other Some methods work with different state Indicates complexity. Candidates to be split Measure of how a component (class/package) depends on other components low high not avoided ad-infinitum managed, instead loose, weak tight, strong Interaction between a limited number of components Changes in coupled components do not propagate Fosters reuse. Watch unnecessary complexity Interactions are spread all over the place Changes in "remote" places propagate themselves Low Coupling High Cohesion Encapsulation OCP, DIP, ISP Same as low coupling + SRP, LSP SRP, LSP, DIP Elements are difficult to understand in isolation Hiding details that are likely to change separation is King abstraction implementation data behavior Low coupling High cohesion Law of Demeter do not talk to strangers container object a parameter a member variable/property objects created within within a method violation of LOD encapsulation broken coupling increased cohesion lowered Tendency of a program to be difficult to change Changes propagate to dependant modules Estimations blow up and fear of change installs Changes break unrelated code Fragile code is an usual host of the bug list Impossibility of logic reuse between projects too much effort and risk in separating part for reuse, therefore... ...no logic is ever reused doing things the right way becomes much more expensive than hacking presents itself in the enviroment, when it "gets in our way" too often "Non-design-preserving-changes" (hacks) proliferate and good engineering practices stop being performed a system is hard to read and understand code is written in an unclear and convoluted way hard to come back code becomes a candidate for rewriting codebase contains infrastructure that adds no immediate value code carries dead weight that would never pay off carrying code maintains repeating structures instead of sound abstractions C&P Programming leads to duplication og bugs ingle R esponsibility P rinciple resiliency to changes increases cohesion lowers coupling pen - C losed P rinciple a class should only have only one reason to change as few responsibilities as possible honoring principle no change software entities should be Open for extension but Closed for modification polymorphism abstractions no break class changes add new functionality when / change existing ones iskov S ubstitution rinciple P subclasses must live up to the expectations set for their parents NotImplementedException downcasting derivatives must be substitutables for their base types "Wilma, Open this door!" "Be water, my friend" "If for each object o1 of type S
there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.” nterface S egregation P rinciple A client should not depend on interfaces it does no use promotes use of cohesive and focused interfaces isolates clients from changes in the abstraction ependency I nversion P rinciple depend upon Abstractions, not concretions change of direction of dependencies comes natural in proper object-oriented code tackles Rigidity degradation is often due to poor management of dependencies crash the "abstraction party" when the component is stable Daniel Gonzalez Garcia
Full transcript