Why I hate all articles about design patterns (2016)

Re:Why I hate all articles about design patterns (2016) by crimsonalucard on Monday March 05, 2018 @10:48AM (#16521795)

Your example has a globally defined function sendEmail. Big OOP languages such as java or C# do not permit that style. You must define all functions as a method of an object if you want to follow the OOP style. You are illustrating a hybrid style of procedural and OO.

    User : NamedTuple[user: str, email: str, group: str]

    func anExampleFilterFunction(any_Tuple_including_User: NamedTuple[str,...]) -> bool

    func filterByAFunction(iterable: List[NamedTuple[str,...]], filter_func: func) -> List[NamedTuple[str,...]]

    func getValuesFromTupleByName(name: str, List[NamedTuple[str,..]]) -> List[str]

    func sendEmails(email_list: List[str], msg: str, subject: str)

Less lines, less cruft, more modular and No objects.

A bit off topic but note that... anExampleFilterFunction can be implemented to filter off of a User and a group at the same time or it can filter off of the email address itself. I could also compose filterByAFunction with itself in an innumerable amount of ways to produce any amount of custom filters:

    //a, b, c are different filter functions. 
    filteredUsers: User = filterByAFunction(filterByAFunction(filterByAFunction(x, a), b), c)
    //or
    filterdUsers: User = filterByAFunction(x, func(y){ return a(y) && b(y) && c(y)})

The tricks(s) above cannot be done if I had everything encapsulated in objects. Objects are not compose-able. You cannot combine User or Group to create a UserAndGroup filter without explicitly defining a whole new class. Also in the end all a program really is doing is calling functions. Classes are just layers of cruft that have no meaning during execution.

[ Parent | on HN ]

Re:Why I hate all articles about design patterns (2016) by rickbad68 on Monday March 05, 2018 @08:03PM (#16526068)

But the requirements were to allow filters to be configured on users and groups, which would require more info in your data structures. This doesn't meet the specified requirements.

Plus even with it not meeting the requirements, it is confusingly presented, and is filled with terminology related to the implementation rather than the domain. Where's a group definition? How would you configure a filter for a group? Or a user for that matter. (Answer: you would require a much more complex data model, and functions to access and modify it).

I'll stick to OO for the top level paradigm I use until something better comes along.

OO being dead is fake news perpetuated by ignorant know-it-alls.

[ Parent | on HN ]

Re:Why I hate all articles about design patterns (2016) by crimsonalucard on Monday March 05, 2018 @09:09PM (#16526346)

Dude. Your group definition Is based on how you define your filter function. That is essentially a group. Users are filtered off the group string in which they belong. Read the code before you respond like a child.

There is zero terminology related to implementation. NOT A single function was defined. All it is are function signatures analogous to your classes.

Read the pseudo code and understand it before you criticize there is enough information in the user tuple type to filter off of users and emails.

You think you are seeing over complexity but my code is actually more simpler and straightforward then your code. NOT to be insulting but you can't see it not because the code is complex but because you lack knowledge.

I'll tell you this. I completely understand your code and I completely understand my code. My judgement is less biased. Respond to me when your level of understanding reached mine.

Nothing gets my blood boiling more then deliberatr ignorance. Read and understand my code before you bitch.

[ Parent | on HN ]