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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
Thanks for your advice Albert, really appreciate it.
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.
Thanks soo much, I would check out the book and practice.
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.
Thanks for this correction! Just what I spotted and I totally agree with your explanation of LSP.
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 ?
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.
Excellent, thank you for sharing your knowledge.
These are some nice and fresh examples right there! :)
Wow this is super easy
dev.to/evrtrabajo/solid-in-php-d8e
I've wrote one in PHP
For DI you mentioned adding the new keyword reduces testability, can you elaborate a little bit more on this? Maybe an Example?
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:
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.
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:
I realy like this article medium.com/backticks-tildes/the-s-...