RedDot Ruby Conf 2014

Los principios SOLID en el desarrollo de aplicaciones Ruby

Anil Wadghule  · 

Presentación

Vídeo

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

alright guys i'm an invertible a I work in company name equal experts which is in Pune India and I'm going to talk about qualities and principles in to be so so this topic is about design principles which I realized helped me to improve my code and

ultimately right good object-oriented code which is extensible and like reusable so all of us are software developers so initially when we write our code or application it is all good version 1 dot o is very good there are no issues but after some time your

application becomes like this with off changes you keep changing your code you keep modifying your code because of client requests and that makes your code bad so your application will change and it will become messy and developers will hate to work on it

it's very it will become very difficult to actually go and add features though mostly I have seen this happening in most of the project so why that happened it happened because of bad design so if your application does not have good design if it doesn't

have like good object-oriented code it will be very difficult to add like new features to it software time it becomes bad so writing model code doesn't mean writing good design so most of the Ruby programmer actually follow Ruby Adams some of the model

rarity concepts so just because you follow dry or TDD doesn't mean you are following good design so good design is about managing dependencies Ruby's object-oriented programming language so everything is object into B so whatever you write are nothing

but objects and how those objects are interacting with each other that makes a good design and that will make your code extensible and like ready for change so these are this in this diagram is dependent on X Y Z so exercise it depend on M this subclass of

T so all these are dependencies and if you don't manage these dependencies well in your application it is going to hurt in future so unmanned managed dependencies are killing your application and a good design might save you so what are smells of bad design

first is rigid rigid means your application is difficult to change one change is causing too many other changes in your system if that's the case it's rigid second is fragile fragile means your application is easily breakable so if you change one part

like if you change controller and suddenly worker is breaking so something is like messed up so that's fragile design immobile so whatever you write should be reusable if you are writing code which is not reducible then it's not of any use so if your

code is hopelessly entangled with each other that makes your application immobile and viscous so viscous means you probably have followed good design but it's very easy to add hacks then actually follow good design if that's the case then that means

your application is viscous so initially it was good so like whenever we write a patient for the first time it was good but after many changes after like new changes new requirements it becomes bad and that's a pattern actually that happens many times

so change is killed it so software development is not a game of Jenga right we don't keep adding features so if we keep adding features without actually thinking about design it will work for like some time but after some time it will become very difficult

to manage that application and in enterprise world this is a pretty common pattern so so why solid So Solid helps us to write loosely coupled highly cohesive easily composable context independent reusable easily testable code so ultimately it makes your code

easy to maintain and extend over time so Robert my teen who is famous as Uncle Bob has written this paper in early two-thousands design principles and design patterns which mentions about dispensable and also a michael feathers coined this term solid so s

means single responsibility o means open closed principle L means Liskov substitution principle I mean Enterprise Solution principle demas dependency inversion principle let's look at these principles in detail first is single responsibility so this principle

[ ... ]

Nota: se han omitido las otras 1.980 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.