Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. The Insider News
  4. Extension methods and the decline of traditional OOP

Extension methods and the decline of traditional OOP

Scheduled Pinned Locked Moved The Insider News
com
7 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    Kent Sharkey
    wrote on last edited by
    #1

    NDepend[^]:

    I didn’t like extension methods back then. I do like them now, provided they aren’t abused.

    "Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."

    B B realJSOPR 3 Replies Last reply
    0
    • K Kent Sharkey

      NDepend[^]:

      I didn’t like extension methods back then. I do like them now, provided they aren’t abused.

      "Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."

      B Offline
      B Offline
      BillWoodruff
      wrote on last edited by
      #2

      Okay, he's had a change of heart: he likes Extension Methods now ... but ... A very interesting article, imho, for the use of quantitative textual analysis on a large sample of open-sauce flavors. My idea of the right thing to do with any programmer who writes an EM on 'object, 'string, or other fundamental language objects: firing squad. blinded by science, Bill

      «Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot

      B 1 Reply Last reply
      0
      • B BillWoodruff

        Okay, he's had a change of heart: he likes Extension Methods now ... but ... A very interesting article, imho, for the use of quantitative textual analysis on a large sample of open-sauce flavors. My idea of the right thing to do with any programmer who writes an EM on 'object, 'string, or other fundamental language objects: firing squad. blinded by science, Bill

        «Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot

        B Offline
        B Offline
        Bernhard Hiller
        wrote on last edited by
        #3

        I disagree. Extension Methods can be useful on any type which you cannot change, no matter if it's a type in the .Net library or a Third Party component. I wrote extensions on string:

            public static string\[\] SplitTrim(this string \_s, char \_separator)
            {
                return \_s.SplitTrim(new\[\] { \_separator });
            }
        
            public static string\[\] SplitTrim(this string \_s, char\[\] \_separator)
            {
                string\[\] split = \_s.Split(\_separator);
                List collector = new List();
                foreach (string item in split)
                {
                    string trimmed = item.Trim();
                    if (trimmed.Length > 0)
                    {
                        collector.Add(trimmed);
                    }
                }
                return collector.ToArray();
            }
        

        Do you see now that they can be useful?

        Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!

        B 1 Reply Last reply
        0
        • K Kent Sharkey

          NDepend[^]:

          I didn’t like extension methods back then. I do like them now, provided they aren’t abused.

          "Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."

          B Offline
          B Offline
          Bernhard Hiller
          wrote on last edited by
          #4

          Quote:

          decline of traditional OOP

          Ehm, that would imply that some when in the past, OOP was in a better state than it is now. The author mentions "Single Responsibility Principle" in his article, which he said was hardly ever observed in his team when Extension Methods were introduced. But let me ask: how many programmers understand the concept of Encapsulation? And that comes before SRP, and SRP is just the first S of SOLID, and ...

          Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!

          1 Reply Last reply
          0
          • K Kent Sharkey

            NDepend[^]:

            I didn’t like extension methods back then. I do like them now, provided they aren’t abused.

            "Anyone even peripherally involved with computers agrees that object-oriented programming (OOP) is the wave of the future. Maybe one in 50 of them has actually tried to use OOP – which has a lot to do with its popularity."

            realJSOPR Offline
            realJSOPR Offline
            realJSOP
            wrote on last edited by
            #5

            The use of extension methods does not negate the use of OOP. Extension methods have their place, and their use should not be discouraged.

            ".45 ACP - because shooting twice is just silly" - JSOP, 2010
            -----
            You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
            -----
            When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

            1 Reply Last reply
            0
            • B Bernhard Hiller

              I disagree. Extension Methods can be useful on any type which you cannot change, no matter if it's a type in the .Net library or a Third Party component. I wrote extensions on string:

                  public static string\[\] SplitTrim(this string \_s, char \_separator)
                  {
                      return \_s.SplitTrim(new\[\] { \_separator });
                  }
              
                  public static string\[\] SplitTrim(this string \_s, char\[\] \_separator)
                  {
                      string\[\] split = \_s.Split(\_separator);
                      List collector = new List();
                      foreach (string item in split)
                      {
                          string trimmed = item.Trim();
                          if (trimmed.Length > 0)
                          {
                              collector.Add(trimmed);
                          }
                      }
                      return collector.ToArray();
                  }
              

              Do you see now that they can be useful?

              Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!

              B Offline
              B Offline
              BillWoodruff
              wrote on last edited by
              #6

              First, I am sure you are among the most experienced, competent, careful programmers; whatever you chose to do, I'd never question. My concern is more that in the context of a complex team project with programmers at different skill/expertise levels that making Extension whoopee with language foundation objects introduces the possibility of broken encapsulation. imho, it's not SOLID. Consider:

              public static class StringUtilities
              {
              public static string[] SplitTrim2(string _s, char _separator)
              {
              return SplitTrim2(_s, new[] { _separator });
              }

              public static string\[\] SplitTrim2(string \_s, char\[\] \_separator)
              {
                  return \_s.Split(\_separator, StringSplitOptions.RemoveEmptyEntries)
                      .Select(str => str.Trim()).Where(str => str.Length > 0).ToArray();
              }
              

              }

              Every programmer using this Class is going to have to reference it per use, or, with a NameSpace 'using statement. In testing and debugging, it is easy, imho, to locate every instance of it's use. In contrast, an Extension Method on 'string ... if in a NameSpace that's accessible by many other project components ... is, imho, an invitation to accidentally use it, possibly create a hard to find dependency. cheers, Bill

              «Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot

              F 1 Reply Last reply
              0
              • B BillWoodruff

                First, I am sure you are among the most experienced, competent, careful programmers; whatever you chose to do, I'd never question. My concern is more that in the context of a complex team project with programmers at different skill/expertise levels that making Extension whoopee with language foundation objects introduces the possibility of broken encapsulation. imho, it's not SOLID. Consider:

                public static class StringUtilities
                {
                public static string[] SplitTrim2(string _s, char _separator)
                {
                return SplitTrim2(_s, new[] { _separator });
                }

                public static string\[\] SplitTrim2(string \_s, char\[\] \_separator)
                {
                    return \_s.Split(\_separator, StringSplitOptions.RemoveEmptyEntries)
                        .Select(str => str.Trim()).Where(str => str.Length > 0).ToArray();
                }
                

                }

                Every programmer using this Class is going to have to reference it per use, or, with a NameSpace 'using statement. In testing and debugging, it is easy, imho, to locate every instance of it's use. In contrast, an Extension Method on 'string ... if in a NameSpace that's accessible by many other project components ... is, imho, an invitation to accidentally use it, possibly create a hard to find dependency. cheers, Bill

                «Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot

                F Offline
                F Offline
                Foothill
                wrote on last edited by
                #7

                My use of extension methods has been pretty limited but targeted in scope. Two such extentions are:

                public static string RemoveWhitespace(this string value);
                // and
                public static string ToEnglishProperCase(this string value);

                I have also used extension methods to perform basic operations that either are not in the .Net Framework or are in there but I haven't found them yet (e.g. adding bytes without casting, getting a sub array of bytes).

                if (Object.DividedByZero == true) { Universe.Implode(); }

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups