DEV Community

SOLID Principles for OOP

Albert Bennett on September 17, 2021

If you learned something new feel free to connect with me on linkedin or follow me on dev.to :) I feel like this is a topic that I don't see many ...

Read full post

Promise Sheggsmann • Sep 18 '21

very cool and informative, I am starting out my career as a software engineer and I admire people who write code like this, but I don't seem to be able to design a program as efficient, extensible and following the principles, can anyone please suggest to me how to learn these skills or at least practice them.

Albert Bennett • Sep 18 '21

I'd second looking at sources surrounding the gang of four as well. In my opinion viewing code samples is always your best bet when learning about code. On top of that it would be worth it to read more into common software design patterns. It helped me out a lot when I first started out. However, if you'd like to learn more about the other aspects of software development I'd suggest reading 'The Pragmatic Programmer' by David Thomas and Andrew Hunt. It's a great book, and one that I find myself going back to every few years.

Promise Sheggsmann • Sep 18 '21

Thanks for your advice Albert, really appreciate it.

taha salman • Sep 18 '21

I would suggest look at gang of four, open source code, other frameworks and…
write code, take an existing implementation and try to do it again. there is no replacement for hands on.

Promise Sheggsmann • Sep 18 '21

Thanks soo much, I would check out the book and practice.

Miro • Sep 20 '21

I do not agree about the example for Liskov Substitution principle. Order and LargeOrder do not inherit IOrder, they implement it. Big difference. For me a right example is something like:
public class Parent {
void DoSomeWork() {};
}
public class Child : Parent {
void DoSomeOtherWork(){};
}

public void Main()
{
Parent p = new Parent();
Child c = new Child();

SomeFunction(p);
SomeFunction(c);
}

private void SomeFunction(Parent p)
{
p.DOSomeWork();
}
This way no matter what child class of the Parent class is used, the SomeFunction will always work as intended and won't know that the parameter is not a Parent class object, but its child.

Branislav Petrović • Sep 24 '21

Thanks for this correction! Just what I spotted and I totally agree with your explanation of LSP.

Junipa • Sep 19 '21

Hello. I am not sure to understand why you wrote "Now to follow the above example you'd need to add an if statement in the calling class for both object and switch between them" in the Open/Close Principle section: since both objects implement the IOrder interface, from my understanding, one could call the MakeOrder() method regardless of the concrete type of the object. Am I missing something ?

Miro • Sep 20 '21

Yes, for me something is not right either. The if statement should be in a Factory class, that knows what object to return. Something like:
We have somewhere a class factory
IOrder OrderFactory(int size)
{
if (size < 100)
return new Order;

return new LargeOrder();
}

and a class using it:
class Foo ()
{
void Bar(int size)
{
IOrder order = OrderFactopy(size);
order.MakeOrder();
}
}
This way the Foo class won't change if somewhere in the future an ExtraLargeOrder class appear. The only place that will change is the OrderFactory class, but all other code won't.

gino greco • Sep 18 '21

Excellent, thank you for sharing your knowledge.

Hanokh Aloni • Sep 18 '21

These are some nice and fresh examples right there! :)

Kapil Patel • Sep 24 '21

Wow this is super easy

Emmanuel Valverde Ramos • Sep 18 '21

dev.to/evrtrabajo/solid-in-php-d8e

I've wrote one in PHP

Nzechi Nwaokoro • Sep 19 '21

For DI you mentioned adding the new keyword reduces testability, can you elaborate a little bit more on this? Maybe an Example?

zankyr • Sep 22 '21

Let's say that you want to test that, by calling BrickLayer.ConstructHouse(), all the exceptions are handled correctly. Using DI allows you to inject a mocked object, configured to throw an exception when required:

// given
BrickLayer mockedBrickLayer = mock(BrickLayer.class);
when(mockedBrickLayer.ConstructHouse()).then(throw new Exception());

// then
assertThrow(new HouseBuilder().BuildHouse(mockedBrickLayer));

In this test case you don't care how or why the exception is thrown (incorrect or missing data etc), you just care about how you're handling that exception. DI allows you to build tests without worrying about the logic within the dependencies (in our case, the BrickLayer).

Another example: what if the BrickLayer.ConstructHouse() bases its logic on external data? For example, data from a database or external API.

public class BrickLayer {

    public void ConstructHouse() {
        // retrieve data from the external
        var externalData = callTheExternalService();

        // do your magic
        if (extarnalData.something()) {
            Console.Writing(...);
        }
    }
}

Without a DI, in your tests you are strictly bound to the response provided by the external system. So, you really have to call the system, which means moving to integration or end-to-end testing.
Using the DI, you don't need a working external system, but you can easily simulate its behavior:

// given
BrickLayer mockedBrickLayer = mock(BrickLayer.class);
when(mockedBrickLayer.ConstructHouse()).then(Console.writing(...));

// when
new HouseBuilder().BuildHouse(mockedBrickLayer));

// then
assertEquals("The expected message", Console.ReadKey());

Janaina Coelho • Sep 20 '21

I realy like this article medium.com/backticks-tildes/the-s-...