[Applause]
salinity and Tesla and I'm here to
quickly talk to you guys about
composition over inheritance in solidity
so quick intro composition and
inheritance came about at the advent of
object-oriented programming and
graphical user interfaces so in these
are brought about classes and objects
and composition Harrisons a how these
personal gesture talk to one another
alikum share code and so he has to pick
that a background about what each one is
let's say I want to make a pizza we have
a pizza base class and in the shape we
have a cheese class and it's got
something about this flavor and we have
a pepperoni class is that a very spicy
we have another function so when we then
want to make a pizza
we can either inherit all of the
previous classes so we have a pizza and
it is a pizza makes cheese and pepperoni
that automatically then gets all the
information that we need suppose she's
in pepperoni got all into the new class
so the pizza is now the same shape as
whatever it inherited we can then use
composition instead as our way of
combining these three and so instead of
inheriting them and also nice link any
one of those functions it has very
important and hasn't you to base it has
cheese and a half pepperoni and if you
want to find out
spicy you look at the pepperoni and ask
the Brittany class so that's just a
quick background on what they are
composition over inheritance or
something introduced I'm a dad for in
1994 living the idea of famous they
basically go through the idea that
inheritance is essentially
whitefox reuse of code so when one class
inherits another it can get all of the
variables the anything that's going on
or computation if you know the right
functions and it's all then included in
one class black box reuse this
composition so where the two classes
interact with one another you can't see
what's going on inside the other classic
run see how the answers and commuting
computers they really care about how
it's implemented you think is interacts
with it get the answers you need and
they argue that this is far simpler it
doesn't matter how long things
implemented as long as you know it's
working so a lot of times of theory and
we also make all contracts oriented
programming so it's very similar to
object-oriented programming but many
analogies centralized computer where
instead of trusting a central party
my contract really does what we think it
does so we also have we put in publicly
on chain which basically means you're
asking people to hack you so you really
really need to be able to look at that
folks
and understand what it's doing we also
have cast costs but I'd say that the
most important thing is readability if
you can't read the smart contracts and
you can't understand what it's doing
you're essentially not the same problem
as the florists how can you really trust
that it's going to work how you think
that's going to this is the quote from I
think the 1980s but it's feeling more
relevant than ever in etherium that
programs must be written for people to
read so in composition we have a
separation of concerns when you want to
read it's not contracts and argue about
what it's doing you can really smart
contract separately you can check in
your head that that concern and it's
doing what it wants to do and then only
at the end do you having an integration
testing that you you can see how the
objects or the all the contracts talk to
each other but before that you can move
about more individually in testable
individually when we bring in
inheritance to read one smart contract
you have to jump between all the ones in
inherit so you drank to understand why
references are variable you can't see
you know what you're looking at either
not a job over to another contract see
that variable see how it's made
contract and so you jump up and forth
between all the files and it's a lot
more complex most importantly multiple
inheritance can act very differently to
how much people think it can and it's
like ups before so let's say we have
this death contract and we've got a
function that says ranadev we have a
solidity depth and the talk function
returns
alright solidity and then calls its
parent contract Eric civility and death
so of course at that party we have the
same thing with a react developer IRET
react over there and then we have
charlie and Charlie is a reactive Oliver
and the salinity develop multiple
inheritance of these two contracts so to
look at what Charlie retirements when
you call talk it obviously starts an
actuality that it's obvious but then one
is stupid on top what was it caught up
to which contract hard to tell in
salinity oh it calls up to the solicitor
caliper and comes out with our excellent
E and that one mammals do not talk from
there but instead of calling the
development one which is faint from
salinity death it actually jumps back
down to the
and I'll put sigh right react and then
from that it finally pulls back up the
top and you can see how that's an
unexpected thing but it's not just in
some of us it happens another object
oriented programming languages as well
but you can easily see how bus might
come in that it's very hard to read what
sort of champions can follow so it's not
all bad it's home grandstand there's
lots of people inherently also 20
contracts for example to to have you
start opens people inherit animal
possible he opens up contracts to and
they're great life cycle things you can
implement in your smile contracts to
keep them safe but there's definitely
complications when you're doing it and
you have to really know what you're
doing to make sure these pups Erica so
that's also a consideration one contract
is cheaper than two if you're just
supplying contract once is that really
well save you $10 just to have you know
about citing sign more complex contracts
the immutability upgrading is easier if
you have composition but people don't
like upgradability necessarily honest so
that's a subject for another tool thank
you very much
this might run for details
[Applause]
you