Hi all!
Ok, another of the principles done. Just one more D = Dependency Inversion Principal. Again, everyone was happy for me to do the next one. The proposed dates are … November 18th 2009 or November 25th 2009. Please let me know your which is prefered.
We covered the theory behind the principle, then looked at and discussed some examples. We discovered how follow the SRP makes this one much easier to adhere to. Another “principle” YAGNI (you aint gonna need it yet) also plays a part in adhering to the ISP.
Put this principle into high gear when designing frameworks, avoid fat interfaces and apply SRP.
We also decided that in december, we’d still meet, but it would be for a supper, so your suggestions are welcome. We can also use it as a time to plan stuff for the new year, so bring along some ideas on what you’d like to see.
Oh! If anyone wants the slides, code etc - let me know
Thanks!
Zak
DevG / Isle of Man software developers group monthly meetings
I’m trying to schedule the next one of the S.O.L.I.D principles - the Liskov substitution principle (LSP) - for the 23rd September 2009. It should be at the same place (Dimension data-Isle of man) and for around the same time - start at 6:30pm
The actual presentation shouldn’t be too long, although based on the previous ones, the actual discussions could go on.
If there’s anything from previous presentations, my BDD testing style (or anything else) that you’d like to discuss, please let me know.
Hope that’s ok..
Thanks
Zak
Hey!
So, we got this one done as well. Thank you to everyone that turned up.
We went through ideas the principles hope to solve, and covered the OCP. We had a look at a couple of solutions on solving the good old “Filter a list of products”.
We also managed to sneak in the Specification pattern and managed to get through some good questions.
Again, everyone was happy enough to continue, so we’ve penciled in the week of the 21st September. I’ll have to confirm a date.
I’ll update the code base for download.
Once again, thanks to everyone.
Zak
Hi All!
Just a quick reminder, the “O” from S.O.L.I.D is up for discussion 19th August 2009. Same place, and similar time.
Hope to see you all there.
Zak
A few design principles to get you going (which are in NO special order). In addition to the basic OO principles, here’s my pin up post on design principles to strive toward (I’ll add to this as we go along).
- Hide details of the implementation: Code to contracts and not implementations. Contracts are either abstract classes or pure interfaces.
- Keep coupling to a minimum : a class can depend on native types (basic ints,bools etc) but should only depend on a select few peer classes. If the dependencies are high, consider this a smell and refactor to reduce the dependency. This can include creating new specialized types that are composed of the dependencies, but again this must be managed correctly.
- Maintain maximum cohesion: a class should focus on a single concept.
- Favour composition over inheritance: there’s a few different ways to get objects to collaborate – inheritance, composition, subscription through event handling.
- Adhere to the Open closed principle: an object should be opened for extension (able to extend its behaviour )but closed for modification (while extending the behaviour you should not modify its source code)
- Follow LSP where possible. Liskov Substitution principle: objects that have references to base types should be able to use derived types without knowing the difference. The basic concept behind polymorphism. TIP: design objects around behaviour and not data.
- Use Inversion of control / Dependency Inversion principle :a formal definition: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
- Employ the Interface Segregation principle: Objects should not be forced to depend on interfaces that they don’t use.
- Consider using the Law of Demeter : Only talk to your immediate friends, so the following would be considered a violation …
- var payment= Client.Wallet.GetMoney(10.00);
- This will be an interesting one to enforce if you plan on sticking to Domain driven design principles which suggest that you should get to entities through their aggregates.
- Encapsulate the variations: when encountering variants encapsulate those bits that vary and make them first class citizens.
- Consider using Factories for object creation.
The above are principles and guidelines and violating them in okay, but only if you understand why doing so is better than following them.
Hope this helps!
