On 17.7.2017 at 6:56 PM, dmatter said:

The original objectmentor PDFs about SOLID are now hosted here: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Definitely read them.

Understanding SOLID is the beginning of a journey away from just being able to write code in C++ and towards being able to architect software and software components. Then to do so on a larger scale without even getting hung up on the specifics of any particular language.

SOLID is often touted as modern pillars of OO and the PDFs are certainly presented from an OO perspective. In actuality you will find that a number of the lessons there can and should be applied to other programming paradigms too!

Thanks, i will have a detail look.

I have the same problem. I notice this.

If follow John Carmack , yes his step from C to C++ is very old one. His newer adventures also years old back is with Haskel. So that Funcional programming with pure Functional languages.

in these day there is still C but C++ is C++ C++98 C++11 C++14 and C++17 so the long livaty of C++ is it legacy support and it still evolving. D is the language is the one wich drops legacy

i Notice hard defending of OOP. But I also Discovered the combination

Functional Reactive programming.

Because CPU get many more cores so side effect less , lockless programming and much easy way of archieve that with paradigm that support it from it core. Without being guru to tackle that major problem of concurrent and parallel programming. In paradigm wich seams to come from the single core time.

John Carmack interrest in Functional programming has to mean something.

What is the relation of functional with DOD

On 7/14/2017 at 2:53 AM, Hodgman said:

...

DOD and OOP can be good friends. OO doesn't really care about data layouts, but OOP languages can default to some bad layouts. C++ is flexible enough to let you apply DOD and come up with better layouts while still getting the maintainability benefits of OO.

OO can also encourage bad data access patterns (thinking per object instead of thinking per batch of objects), which can be bad for performance on modern CPU's (where cycles are cheap by memory access is death). This is where you can use a hybrid of OOP and DOD. Often this manifests as creating "systems" (e.g. "particle system" class, but no "particle" class) and representing objects by some form of opaque handle. C++'s flexibility again gives endless options here. Sometimes you still have individual objects as classes as well as a "system", but move certain methods to the system from the object to force users into better data access patterns. Other times you still have traditional objects, but you just use DOD thinking to arrange them into better layouts, or restructure the algorithms that operate on them to make better use of the real hardware.

...

2

3

Won't you have an issue with member variables filling the cache even when you don't need access to them using this approach? Thanks!

12 hours ago, Bouke285 said:

Won't you have an issue with member variables filling the cache even when you don't need access to them using this approach? Thanks!

Well, that's what I meant by using using DOD to come up with better layouts for your OOP objects.

e.g. If you've got an OOP object where 50% of the member variables are used in data-transformation A, and the other 50% are only used in data-transformation B, then maybe you should split it into two different classes. Note that in that situation, you were probably violating OO's SRP rule in the first place, and by following DOD you're actually getting closer to pure OO theory

Lots of introductory OO classes start with some problem like "Say we've got students and teachers, we can make three classes: Student, Teacher and Person, and Student/Teacher will inherit from Person"... well that's bullshit. It does show you what inheritance is, but it's a complete violation of OO theory. You can't go designing your object layouts/hierarchy until you know what the algorithms are / what the problem you're trying to solve is. Without knowing what the algorithms are, it's impossible to know if inheritance is valid here or not.

Likewise, DOD wants you to very closely inspect your algorithms and the flow of data between them, and then design data layouts that cause the least friction. It's actually good practice for OOP programmers to work this way, instead of trying to design self-contained objects first, without thinking about the big picture algorithms or data flow at all.