five core principles for effective Object Oriented Programming, and is fundamental core knowledge for any developer. • SOLID principles were defined in the early 2000s by the “God of OOP” Robert C Martin (Uncle Bob) as a way of effective management of dependencies in code. • It was a chap called Michael Feathers that applied Bob’s principles to the acronym SOLID.
recommendations that help us obtain the following benefits when applied to our code: • Code is easy to maintain. • Code is easy to extend. • Code is robust.
reason to change.” • Or put in a better way, a class should have only one responsibility. A class should do one thing, and do it well. • Mixed responsibilities are not conducive to change. • An example would be don’t put HTML or even call a service which renders HTML in a controller. • Instead, inject a service responsible for rendering output. • Take this with a pinch of salt, perfect design is often not practical.
should be open for extension, but closed for modification.” • All this means is that a class should be extendable without modifying the class itself. • Open for extension: new behaviour can be added to satisfy the new requirements. • Closed for modification: by extending the new behaviour we are not required to modify the existing code. • Use an interface, interfaces are your friend. Something conforming to an interface makes it simple to code another implementation.
replaceable with instances of their subtypes without altering the correctness of that program.” • All this means is every subclass should be substitutable for its parent class. • if you’re a good developer and have coded to an interface and your class returns a value, then that value type must be consistent. • For example a repository interface with getResult and the callee expects an array. If you have another implementation that returns an object the callee doesn’t know how to handle it. • Put another way - any code calling a derived class should be generic and not change per implementation. It should behave in the same way!
one general-purpose interface.” • A class must not be forced to implement interface methods it does not use. • Do not implement a FAT interface. • Implement an interface fit for purpose. • A FAT interface violates SRP as it indicates the interface is handling more than one responsibility. • Remember a class can implement multiple interfaces. • Benefits: decoupled system that is easy to refactor.
low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.” • This means that a class should not directly depend on another class, but instead on an interface of the class. • This reduces coupling and makes code more reusable. • Imagine a logger class as an example, each logger does something different yet they all need to work the same.
is, the simpler it will be to maintain in the future. • Simple code is easy to read by fellow developers. • This is one of my favourites after writing magical code in the past.
means don’t overthink, or over engineer software. • Don’t implement functionality you think you might need, only implement what you do need. • By following SOLID principles it should be easy to add extra functionality later.
a single, unambiguous, authoritative representation within a system” - The Pragmatic Programmer. • Simply try not to duplicate bits of functionality all over the place that can be easily shared. • By “knowledge” in the quote above they mean business logic. Don’t duplicate any implementation of business logic, e.g. an APR quotation function. • Take with a pint of salt, don’t try to abstract EVERYTHING into little classes. You’ll end up with an unmaintainable nightmare that is hard to follow.
mbtaylor
takeda_h
recruitengineers
yussak
cygames
takaking22
lhazy
chimaki_iot
hatappi
miyuc
sansan33
puku0x
upura
tenderlove
elsirapls
skipperchong
csswizardry
portentint
bluesmoon
smashingmag
marktimemedia
katarinadahlin
tammyeverts
schlessera
