Leaderboard

I found something... not mine.... actually, the original thoughts on leaky abstractions https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

Non-implementation detail = the interface declaration - i.e. the black box UI - the what. Implementation detail = how an interface has been implemented - i.e. the inside of black box - the how. You want to use the first, and avoid relying on details from the second.

Original post: https://www.thedelphigeek.com/2019/02/design-patterns-with-delphi-book.html Hurrah, hurray, my third book is here! It’s called Hands-On Design Patterns with Delphi and (just like my first book) I wrote it for Packt Publishing. (The second book was self-published and I expect the fourth one to be, too.) As the name says, “Design Patterns with Delphi” deals with design patterns. It is a bit different from most of design pattern books and websites you will find on the Internet. Case in point A: There are no UML diagrams. I don‘t speak UML. Tried to learn it few times but for some reason the whole concept doesn‘t agree with me. If you like diagrams, don’t fear though. Any book on design patterns - and most websites covering that topic - will gladly show how any design pattern can be diagrammed. That, however, is not important and should not govern your decision to buy the book. More important is case in point B: This book speaks Delphi. All the examples are written in Delphi and language features are used to the full. I also covered few less known Delphi idioms in separate sections. You’ll still be able to follow the discussion even though you may program in a different Pascal dialect. There’s also case in point 😄 Examples make sense. I deeply dislike classical design pattern examples of the “And then we want to write this program for different toolkits and it should also be able to draw circles, not only squares” kind. Euch! I tried to find a good example for each design pattern. Admittedly, I ended with few examples that draw triangles and squares on screen (mostly because some patterns were designed specifically for solving such problems), but most of them are of a more practical nature. This book covers all three classical design pattern categories - Creational patterns, Structural patterns, and Behavioral patterns. It also discusses patterns from the newer Concurrency patterns category. At the end I threw in some borderline-pattern(ish) topics and ended with a discussion of few patterns that cannot be strictly classified as “design” patterns. In this book you’ll find: Chapter 1 An introduction to patterns. Exploration of design principles, design patterns, and idioms. A mention of anti-patterns. A short description of most important design principles. Delphi idioms: creating and destroying objects. Chapter 2 Creation patterns part 1. Singleton. Dependency injection. Lazy initialization. Object pool. Chapter 3 Creation patterns part 2. Factory method, Abstract factory, Prototype, Builder. Delphi idioms: Assign and AssignTo. Chapter 4 Structural patterns part 1. Composite. Flyweight. Marker interface. Bridge. Delphi idioms: comparers and hashers. Chapter 5 Structure patterns part 2. Adapter. Proxy. Decorator. Facade. Delphi idioms: replacing components in runtime. Also: helpers. Chapter 6 Behavioral patterns part 1. Null object. Template method. Command. State. Chapter 7 Behavioral patterns part 2. Iterator. Visitor. Observer. Memento. Delphi idioms: for .. in. Chapter 8 Concurrency patterns part 1. Locking. Lock striping. Double-checked locking. Optimistic locking. Readers-writers lock. Delphi idioms: tasks and threads. Also: bitwise operators. Chapter 9 Concurrency patterns part 2. Thread pool. Messaging. Future. Pipeline. Chapter 10 Writing Delphi programs. Event-driven programming. Actions. LiveBindings. Form inheritance. Frames. Data modules. Chapter 11 Wrapping it up. Exceptions. Debugging. Functional programming. I hope you will like this book and learn a lot from it. I know I did during the nine months I spent writing it. And if you find any bug in the code, let me know so I can correct it in the second release!

https://sdtimes.com/softwaredev/industry-watch-the-developer-transformation/

Sorry, but you started going off rails saying that you should not use fabc.ToString for displaying integer value as text, thus blowing the whole encapsulation and hiding the implementation thing out of proportion. Now, it is possible that you just used poor example and that you actually tried to say something completely different. I am not trying to shred concepts to pieces, I am just trying to show their usage must be balanced. Abusing the concepts to the point of absurdity is as bad as not using them at all. What better example to show how not everything can be absolutely hidden and protected than to show that strings itself are leaking their implementation details.

You have a problem so you decide to use threads. you problems.2 have Now

I know for sure that it doesn't work for more than one readers, my implementation is specific for single reader and I plan to add checks to make sure only one thread reads. If you see GetItem(), I intentionally used Inc() and not Interlocked version knowing that only one reader will exist. Having that in mind, Primož Gabrijelčič, do you think it's a good start? Also thank you dummzeuch for your reply, will check your implementation.

Definitely doesn't work correctly. For starters, two parallel readers would clash horribly. If you want to implement lock-free structures, start by writing thorough stress-tests. They should run different scenarios - one reader, few readers, many readers ... very many readers (more than the number of cores in the system) - in a loop which runs for a long time (minutes, at least, preferably more). If you want to use something that is well-tested, take TOmniBoundedQueue from the OmniThreadLibrary.

Normal Delphi objects, using the Windows compiler, does NOT have garbage collection or any kind of automatic memory management like Java, C# etc. This means if you merely assign "nil" to an object reference, the memory pointed to originally by that reference is still allocated in the heap somewhere, but now "lost" -- you've caused a memory leak(!). Normal objects should be disposed of by calling the destructor, e.g. var LMyLocalObj : TSomeClass; begin LMyLocalObj := TSomeClass.Create(...); try //do something with LMyLocalObj finally LMyLocalObj.Free; //or if you prefer FreeAndNil(LMyLocalObj); end; // more code perhaps... end; Setting the reference to nil is a safeguard since if you do not do this then the value of the object reference will point to where the now-freed object used to be. For a while this may still look valid if accidentally used/derefenced, whereas if you reset the reference variable to nil then trying to dereference it will cause an access violation to be raised to alert you to the misuse. If there's no further use of the variable however in the current scope then setting to nil of course is redundant and serves no purpose. You should carefully review and ideally check your programs for memory leaks using for example the memory leak checking features of FastMM or some other tool. (There are several.) All that said, there are forms of automatic memory management available in Delphi on Windows: Interfaces support reference counting based memory management whereby the compiler will automatically free an interfaced object referenced via an interface reference when the enclosing method/function terminates, via code the compiler generates to check the reference count and act when it reaches zero. You should not manually free an interfaced object as this in turn may also cause an exception when the compiler auto-generated code also tries to free the object. This is a so-called "double-free" error. FastMM (or some other tool) can also be employed to help detect this type of mistake. Additionally please note that Embarcadero decided arguably somewhat controversially (in a departure from the behaviour on Windows) to adopt similar semantics for plain objects on the Delphi mobile compilers, this is commonly referred to as ARC ("Automatic Reference Counting", see here). So, when you write Delphi code and compile for a mobile target, then you do not need to explicitly call .Free() or even set to "nil" since the object will be automatically freed when its reference count hits zero. However, because of vaious reasons including not least the runtime cost of ARC and the conflicting semantics between the platforms, it looks like Embarcadero is now going to revert to making the mobile compilers behave the same as on Windows after Delphi 10.3 Rio, see here: http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html I hope that helps.

OK, I'll do that since this is simple, but I won't test so won't know if it breaks modern compilers, I assume you can do that? Listing a few canges is acceptable, any more and I need emailed complete units, particularly anything C++ related which I can not test. Angus

Sorry no idea, that line is there for historic reasons for reasons I don't understand since I don't use C++, but I nearly always get caught out when I remove stuff I believe is unwanted. But I've commented it out here. Angus

Not all of it. It only hides the integer, but it does not hide how you implemented conversion from integer to string. Also, string type itself leaks its implementation details in Delphi all over the place. You are going extra mile to hide just about everything - without real reasons. Point is, no matter how far you go, you can never hide all implementation details. In one way or another they will leak. It is perfectly acceptable to have integer function or property as part of well defined public API. The whole point of hiding implementation details, and not using them is that by doing so, you can change implementation without changing the public interface and without need to change all the code that relies upon it. That is the purpose of having well defined public API. Hiding inner collection implementation (so you can easily replace plain array with list or some other structure) or some other more complex data is one thing, but hiding basic type like integer is going over the top without actually accomplishing anything. One of the problems when it comes to following good practices like testing, proper OOP design... is that quite often those practices are explained and taught by going into extremes, making them overly complicated and losing original intent - making better, more maintainable code, with less bugs. That blowing things out of proportion, not only makes it harder to understand basic principles behind those practices but it also makes many developers just to drop the whole thing and not use any. It is hard to blame them when they see no point.

Added: -x-fpr generates 3 times faster stack memory page probing code (RSP-19826) Added: Options -x-O1, -x-O2, -x-O3, -x-Ox that enable other optimization options More info.... Hope these optimizations would come to Delphi compiler directly. https://andy.jgknet.de/blog/2017/10/ide-fix-pack-6-1-released/ https://andy.jgknet.de/blog/2018/06/ide-fix-pack-6-3-released/

You can find my street address in the comments in front of each ICS source file.