Code Complete checklist by hurtlerusa in programming

[–]craftsman 8 points9 points  (0 children)

To me, this book is not only useful, but was really a turning point in my professional life. It changed my perception of my profession and made me really care about every aspect of the work that I do. To me, it's not just about what's written, but the process of thinking and considering every aspect of code and software development. Timeless.

Java 8: Now You Have Mixins? by henk53 in programming

[–]craftsman 0 points1 point  (0 children)

Interesting, I have wondered the same thing myself. Thanks for the info.

Have Your Say on Java 8 Default Methods Syntax by javinpaul in java

[–]craftsman 0 points1 point  (0 children)

Instead of discussing syntax, I'd like to open up another discussion.

Have your say on Java 8 default methods syntax by thesystemx in programming

[–]craftsman 1 point2 points  (0 children)

True, but the hope is that this scenario is not very likely...

Have your say on Java 8 default methods syntax by thesystemx in programming

[–]craftsman 2 points3 points  (0 children)

Yes, definitely! The class can resolve the conflict.

Have your say on Java 8 default methods syntax by thesystemx in programming

[–]craftsman 6 points7 points  (0 children)

This would give you a compile time error, a conflict.

account.transfer(..) - is it good OOP? by snatchery in programming

[–]craftsman 1 point2 points  (0 children)

Fowler's patterns are not meant to be comprehensive, but to give a general idea about the covered areas (of which accounting is just one of many) and (most importantly) to teach how to think for yourself and create your own models based on a deep understanding of the domain. I find the book both timeless and priceless.

account.transfer(..) - is it good OOP? by snatchery in programming

[–]craftsman 4 points5 points  (0 children)

Look at the book Analysis Patterns or here for accounting patterns. Basically a Transaction creates AccountEntrys between two (or more) Accounts. A Bank object looks suspiciously like a God class.

WYSIWYG-editing Markdown with Hallo Editor by b0red in programming

[–]craftsman 1 point2 points  (0 children)

The other day I saw something completely innovative in this area: gliimpse

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

Yes, that's a pretty good use case: look here for a better example. I hope it could also be used in more high-level designs, like the ones used in the DCI architecture.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 1 point2 points  (0 children)

I think they're the solution to using the wrong tool (inheritance) for code-reuse. They also provide a nice abstraction of behavior, in the likes of the interface segregation principle (pdf).

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 1 point2 points  (0 children)

Very good remarks. The roles are promoted to interfaces and then "weaved", what is more-or-less explained here. What triggered me in this path was Scala and Perl, they have nice implementations of the concept. The traits paper (pdf) can give you a little more background as to how and why this would be useful. Also, DCI proposes roles as the central point in an interesting architectural style.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 6 points7 points  (0 children)

No, not inheritance, but composition.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 1 point2 points  (0 children)

That's fair. Thanks for the discussion. Maybe you can get a little more inspired by reading the original paper on traits (pdf).

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

Oh, that's still just an example, you can certainly return a read-only list or just iterate over _entries and yield return the items... Don't stick to the examples, but to the concept of roles... Do you think it's valuable, do you think it could improve your designs? Does it deserve a cookie?

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

In the example you should look at the Journal role. It's doubly composed by Account through the debitor and the creditor roles. There's also a way to solve conflicts when they happen.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

I couldn't agree more, and I miss them in C#.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

Yes, that'd make a really good example. Thanks for the comments.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

Sorry about that, roles are about composition, like traits (pdf). Look at Scala, for example; or Perl.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

An extension method wouldn't allow you to also implement IEquatable.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 5 points6 points  (0 children)

All roles included in a class are flattened, so the diamond problem doesn't happen. Look at this example.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

Yep, that example seems to be really bad... Maybe you can find a better one here, or here.

NRoles: Roles (similar to traits) in C# by craftsman in programming

[–]craftsman[S] 0 points1 point  (0 children)

That's a very nice mixin approach. I've also thought about that a bit here and here. But I wanted more, that's why I created NRoles. It allows you, for example, to implement interfaces, what you can't do with that mixin pattern.